0% found this document useful (0 votes)
6 views12 pages

Data Definition Language Define and Manage The Structure

DDL (Data Definition Language) is a subset of SQL used to define and manage database structures such as tables and schemas, with key commands including CREATE, ALTER, DROP, TRUNCATE, and RENAME. PostgreSQL-specific examples illustrate how to manipulate tables and data types effectively, emphasizing the importance of selecting appropriate data types for efficient storage. Additionally, the document explains the differences between DDL and DML, highlighting that DELETE is a DML command used for data manipulation, not structure definition.

Uploaded by

guldariya299
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views12 pages

Data Definition Language Define and Manage The Structure

DDL (Data Definition Language) is a subset of SQL used to define and manage database structures such as tables and schemas, with key commands including CREATE, ALTER, DROP, TRUNCATE, and RENAME. PostgreSQL-specific examples illustrate how to manipulate tables and data types effectively, emphasizing the importance of selecting appropriate data types for efficient storage. Additionally, the document explains the differences between DDL and DML, highlighting that DELETE is a DML command used for data manipulation, not structure definition.

Uploaded by

guldariya299
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 12

1.

​ DDL
WHAT: DDL stands for Data Definition Language. It is a part of SQL (Structured Query
Language) used to define and manage the structure of database objects like tables, views,
indexes, and schemas.

Main DDL Commands:

1.​ CREATE – To create new database objects (tables, databases, views, etc.)
2.​ ALTER – To modify existing database structures (add/remove columns, change data
types, etc.)
3.​ DROP – To permanently delete database objects.
4.​ TRUNCATE – To quickly remove all rows from a table (faster than DELETE, and
cannot be rolled back).
5.​ RENAME – To rename database objects like tables or columns (supported in many
SQL versions).

EXAMPLE:

1. CREATE is Used to create a new table or other object in the database.


CREATE TABLE Employees (
ID INT,
Name VARCHAR(50),
Salary DECIMAL(10, 2) );

➡️ This creates a table named "Employees" with 3 columns: ID, Name, and Salary.
2. ALTER is Used to modify the structure of an existing table.

ALTER TABLE Employees ADD Email VARCHAR(100);

➡️ This adds a new column called "Email" to the "Employees" table.


3. DROP is Used to delete a table or other database object permanently.

DROP TABLE Employees;

➡️ This completely removes the "Employees" table and all of its data.
4. TRUNCATE is Used to remove all data from a table, but keep the table structure.
TRUNCATE TABLE Employees;

➡️ This deletes all rows in "Employees" but keeps the table itself for future use.
5. RENAME is Used to change the name of a table or column.

RENAME TABLE Employees TO Staff;

➡️ This renames the "Employees" table to "Staff".


PRACTICE Q:

PostgreSQL-Specific Notes + DDL Examples

✅ 1. Rename a column in PostgreSQL


ALTER TABLE Employees RENAME COLUMN Name TO FullName;

✅ 2. Change data type of a column


ALTER TABLE Employees ALTER COLUMN Salary TYPE FLOAT;

✅ 3. Add a new column

✅ 4. Drop a column
ALTER TABLE Employees ADD COLUMN Department VARCHAR(50);

ALTER TABLE Employees DROP COLUMN Department;

✅ 5. Truncate a table
TRUNCATE TABLE Employees;

In PostgreSQL, TRUNCATE is faster than DELETE and also automatically


commits the transaction.

✅ 6. Drop a table
DROP TABLE Employees;

✅ 7. Rename a table
ALTER TABLE Employees RENAME TO Staff;

🔥 PostgreSQL-specific interview questions they might ask


Question What they’re Sample Answer
testing

What happens when you Behavior of It quickly deletes all rows, auto-commits,
TRUNCATE a table in DDL in PG and doesn’t activate triggers unless they
PostgreSQL? are AFTER TRUNCATE triggers.

How is TRUNCATE DDL vs DML TRUNCATE is a DDL command — faster and


different from DELETE in cannot be rolled back unless inside a
PostgreSQL? transaction. DELETE is DML and can be
rolled back.

Can you roll back a DROP Transactions No, unless it's inside a transaction and you
command in PostgreSQL? ROLLBACK before commit.
PRACTICE Q2: Here are the most common types of coding examples they might ask, with
examples ready to go:

💻 1. Create a Table
"Write a SQL statement to create a table for storing student data."

CREATE TABLE Students (


StudentID SERIAL PRIMARY KEY,
FullName VARCHAR(100),
Age INT,
Email VARCHAR(100),
EnrolledDate DATE );

🧱 2. Alter a Table
"Add a new column to store the student’s course name."

ALTER TABLE Students ADD COLUMN CourseName VARCHAR(100);

"Change the data type of Age to SMALLINT."

ALTER TABLE Students ALTER COLUMN Age TYPE SMALLINT;

🗑️ 3. Truncate Table
"Write a command to delete all rows from the table without deleting the table
itself."

TRUNCATE TABLE Students;

🧨 4. Drop Table
"Write a command to completely delete the Students table."

DROP TABLE Students;

🔁 5. Rename Table or Column


"Rename the Students table to Learners."

ALTER TABLE Students RENAME TO Learners;

"Rename the column FullName to Name."

ALTER TABLE Learners RENAME COLUMN FullName TO Name;

🧠 Bonus: Combo Questions


They might give a scenario like:

"You created a table but forgot to add an email column. Then you realize the table
name should be 'Users' instead of 'Accounts'. Fix it."

ALTER TABLE Accounts ADD COLUMN Email VARCHAR(100);


ALTER TABLE Accounts RENAME TO Users;
Use the appropriate data types when creating database objects. Choosing the correct data
type for each column ensures that the data is stored efficiently and accurately. Here are
some guidelines for selecting the correct data types:

●​ Use the smallest possible data type that can accommodate the values you need to
store. For example, use SMALLINT instead of INT if the column will only contain
small integers.
●​ Use numeric data types such as INTEGER or DECIMAL for numeric values. Don't use
character data types to store numbers.
●​ Use character data types such as VARCHAR or CHAR for character data. Don't use
numeric data types to store character data.
●​ Use the appropriate data type for dates and times—e.g., DATE, TIME, or TIMESTAMP.
●​ Avoid using generic data types like VARCHAR without specifying a length, which can
lead to unexpected behavior.
●​ Be aware of the maximum and minimum values that can be stored in each data type,
and choose a data type that can accommodate the range of values you need to store.

🗓️ 1. DATE
●​ Stores just the calendar date (year, month, day)
●​ No time information

birth_date DATE;
-- Example: '2025-04-22'

⏰ 2. TIME
●​ Stores only the time of day (hours, minutes, seconds)
●​ No date
●​ Optionally with TIME WITHOUT TIME ZONE or TIME WITH TIME ZONE (rarely needed
unless you're dealing with different regions)

appointment_time TIME;
-- Example: '14:30:00'

🕒 3. TIMESTAMP
●​ Stores date + time
●​ Use TIMESTAMP WITHOUT TIME ZONE by default
●​ Or TIMESTAMP WITH TIME ZONE (often called timestamptz)

created_at TIMESTAMP;
-- Example: '2025-04-22 14:30:00'

🔄 Cheat Sheet
Type What It Stores Example Value

DATE Just the date '2025-04-22'

TIME Just the time '14:30:00'

TIMESTAM Date + time '2025-04-22 14:30:00'


P

TIMESTAM Date + time + time zone '2025-04-22 14:30:00+00'


PTZ offset
Yesss exactly! 🔍 EXTRACT is one of the go-to tools in PostgreSQL when you want to pull
out specific parts of a date/time value — like the year, month, day, hour, etc.

Here’s how it works:

🔧 Basic Syntax:
EXTRACT(part FROM source)

●​ part = what you want to pull (like YEAR, MONTH, DAY, HOUR, etc.)
●​ source = your column or value

📦 Examples:
1. Get the year someone signed up:

SELECT EXTRACT(YEAR FROM created_at) AS signup_year


FROM users;

2. Find all products made in April:

SELECT *
FROM paper_world.product
WHERE EXTRACT(MONTH FROM production_date) = 4;

3. Get hour of the order (if using TIMESTAMP):

SELECT EXTRACT(HOUR FROM order_time) AS order_hour


FROM orders;

4. Group by year or month (super useful in reports):

SELECT
EXTRACT(YEAR FROM production_date) AS prod_year,
COUNT(*) AS product_count
FROM paper_world.product
GROUP BY prod_year
ORDER BY prod_year;

⚠️ Note:
EXTRACT returns a double precision number (so you might see 2025.0), but you can cast it
to an integer if you want:

SELECT EXTRACT(YEAR FROM production_date)::INT

:: what does this...


ChatGPT сказал:m Ahhh good catch! The :: in PostgreSQL is the type cast operator — it’s
shorthand for converting one data type to another.

🔧 Example:
SELECT EXTRACT(YEAR FROM production_date)::INT
This means:​
“Take the year from production_date and convert it into an integer.”

Because EXTRACT() gives you a double precision number (like 2025.0), if you want a clean
2025 (no decimal), you cast it to an INT (integer).

🧠 You can also use the full CAST() function:


SELECT CAST(EXTRACT(YEAR FROM production_date) AS INT)

But most people just go with the :: — it’s shorter and more common in PostgreSQL.

🎯 More casting examples:


'2025-04-22'::DATE -- string to date
NOW()::TIMESTAMP -- current time to timestamp
'123'::INT -- string to integer
42::TEXT -- number to string

What is VARCHAR(n)?

●​ VARCHAR(n) = variable-length character string, with a maximum of n characters


●​ So VARCHAR(50) means:​

"Store a text value that can be up to 50 characters long."

🎯 When to use it vs other options:


Type Description Example Use Case

VARCHAR(5 Limit to 50 chars Short names, usernames, titles


0)

VARCHAR(2 Common default for text fields Emails, longer names, etc.
55)

TEXT No length limit Comments, bios, descriptions,


etc.
❓ So... why not always use TEXT?
Good question.

●​ Functionally, VARCHAR(n) and TEXT are almost the same in PostgreSQL — there’s no
performance difference for most use cases.

But constraints are easier with VARCHAR(n), like:​



CHECK (LENGTH(name) >= 3)

●​ Validation: If you know a value shouldn’t be longer than 50 chars (e.g., first name),
use VARCHAR(50).​

💡 Pro Tip:
If you’re not sure how long values will be, and length isn't important for validation or logic,
just go with TEXT.
does varchar contain string, how about mixed data with numbers

ChatGPT сказал: Yup — VARCHAR absolutely contains strings, and that includes any mix of:

●​ Letters (A–Z, a–z) ✅​


●​ Numbers (0–9) ✅​
●​ Symbols (@, #, $, etc.) ✅​
●​ Emojis, Unicode — anything that’s text ✅​
📦 Example:
INSERT INTO users (username)
VALUES ('john123'), ('amy_01'), ('user#789');

All those values go into a VARCHAR column — no problem.

🔥 Mixed content? Still fine:


product_code VARCHAR(20);

Values like:

●​ 'X100'​

●​ '1234-ABCD'​

●​ 'BATCH2025'​
All totally valid.

🚫 What VARCHAR is not:


It’s not a numeric type — so you can’t do math on it directly:

SELECT '123' + 5; -- ❌ will throw error, unless cast to integer


But you can cast strings to numbers if needed:

SELECT '123'::INT + 5; -- ✅ result: 128


🧠 TL;DR
●​ VARCHAR holds any sequence of characters, including letters, numbers, symbols.
●​ It doesn’t care what’s inside — as long as it’s text.
●​ Want to do math? Use INT, NUMERIC, or cast the string.

🔢 What is SERIAL in PostgreSQL?


SERIAL is a convenience data type that:

●​ Creates an auto-incrementing integer column


●​ Automatically sets up a sequence behind the scenes
●​ Automatically adds a DEFAULT value that pulls from that sequence​

So when you write:


product_id SERIAL PRIMARY KEY

PostgreSQL is secretly doing something like this:

product_id INTEGER NOT NULL DEFAULT nextval('product_id_seq')

And it creates a sequence like:

CREATE SEQUENCE product_id_seq START 1 INCREMENT 1;

🧠 TL;DR:
Type Max Value Behind the scenes

SERIAL ~2 billion (INTEGER) Uses nextval() on a sequence

BIGSERIAL ~9 quintillion (BIGINT) Same idea, just bigger

SMALLSERI ~32k (SMALLINT) Rare, for tiny ID ranges


AL

⚠️ Small Note:
As of newer PostgreSQL versions (v10+), the recommendation is to use GENERATED syntax
instead:

user_id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY

But SERIAL still works great and is widely used.

🧱 If you use just INT:


user_id INT PRIMARY KEY

You’ve defined a column that can hold integers... but nothing more:

●​ No default value ✅😬
😐
●​ No auto-increment
●​ No sequence ​

So when you insert a row, you must manually provide the ID every time:

-- You have to do this manually


INSERT INTO users (user_id, username) VALUES (1, 'alice');

And now you're the one tracking and avoiding duplicate IDs... which is 😩
🔥 If you use SERIAL:
user_id SERIAL PRIMARY KEY

You get this magic for free:

●​ A sequence that auto-generates numbers


●​ A default value like nextval('user_id_seq')
●​ IDs that just auto-increment as you insert
●​ You never have to worry about duplicates or tracking the count​

-- This works perfectly


INSERT INTO users (username) VALUES ('bob');
-- Automatically assigns user_id = 2

SEQUENCE:

💡 What's Going On?


In your example:

CREATE SEQUENCE IF NOT EXISTS vendue.employee_role_id_seq START WITH 11000;

ALTER TABLE IF EXISTS vendue.employee_role


ALTER COLUMN employee_role_id SET DEFAULT nextval('employee_role_id_seq');

You're manually setting up a sequence to auto-generate IDs for the employee_role_id column
in the vendue.employee_role table.

🔍 Breakdown:
Creating the sequence:​

CREATE SEQUENCE IF NOT EXISTS vendue.employee_role_id_seq START WITH 11000;

○​ CREATE SEQUENCE creates a sequence called employee_role_id_seq in the


vendue schema.​

○​ The START WITH 11000 part tells PostgreSQL to start the sequence at
11,000 (so the first ID generated will be 11000).​

○​ The sequence will automatically increment by 1 unless you specify a different


increment.​

Using the sequence with nextval():​



ALTER TABLE IF EXISTS vendue.employee_role
ALTER COLUMN employee_role_id SET DEFAULT nextval('employee_role_id_seq');

2.​
○​ ALTER TABLE modifies the employee_role table.​

○​ ALTER COLUMN employee_role_id SET DEFAULT


nextval('employee_role_id_seq') does the magic:​

■​ nextval('employee_role_id_seq') tells PostgreSQL: "Fetch the next


value from the sequence 'employee_role_id_seq' and use it as the
default value for the employee_role_id column."

🎯 So, where does nextval() come from?


●​ nextval() is a PostgreSQL function that returns the next value from a sequence.
●​ Sequences in PostgreSQL are special objects that generate unique, incrementing
numbers (like IDs) each time you call nextval() on them.
●​ The sequence employee_role_id_seq is like a counter, and nextval() fetches the next
number in line for use.​

🌟 Example Walkthrough:
Step 1: When you insert a new row into employee_role, PostgreSQL will automatically use
nextval('employee_role_id_seq') to get the next number in the sequence.​


INSERT INTO vendue.employee_role (employee_role_name) VALUES ('Manager');

●​ Step 2: PostgreSQL will automatically insert the next value in the sequence (11000
on the first insert, then 11001, 11002, etc.) into the employee_role_id column,
because you've set it as the default for that column.

No, you cannot use DELETE in DDL (Data Definition Language)

The DELETE statement is actually part of DML (Data Manipulation Language), not DDL.

●​ DDL deals with defining, modifying, and dropping database structures like tables,
schemas, indexes, etc. (CREATE, ALTER, DROP)
●​ DML deals with data inside the tables, like inserting, updating, or deleting rows.
(SELECT, INSERT, UPDATE, DELETE)​

So, when you run something like:

DELETE FROM table_name WHERE condition;

That’s a DML statement, and it’s about manipulating the data in the table, not changing the
table structure.

⚙️ When Do You Use DELETE?


You would use DELETE to remove rows from a table. Here's a simple example:

DELETE FROM employees WHERE employee_id = 5;

This deletes the row where the employee_id is 5 from the employees table.

🧠 Key Difference Between DDL and DML:


Type Command Purpose

DDL CREATE, ALTER, DROP Defines or modifies database objects (e.g., tables)

DML INSERT, UPDATE, Manipulates the data in those objects (e.g.,


DELETE, SELECT adding/removing rows)
✅ TL;DR:
●​ DELETE is a DML statement — it manipulates data, not the structure of the table.
●​ DDL doesn’t include DELETE; it only includes commands like CREATE, ALTER, and
DROP.
🧠 What is pg_catalog in PostgreSQL?
pg_catalog is a built-in schema in PostgreSQL that contains the system tables — the core
internal metadata that PostgreSQL uses to keep track of everything.

It’s like the brain of the database 🧠 — holding all the information about:
●​ Databases
●​ Tables
●​ Columns
●​ Indexes
●​ Users/Roles
●​ Schemas
●​ Permissions
●​ Functions
●​ ...and more​
🔎 So what's a schema, again?
Think of a schema like a folder or a namespace inside a database.

●​ Default schema for user tables: public


●​ Default schema for system stuff: pg_catalog​

So when you run:

SELECT * FROM pg_database;

That’s actually:

SELECT * FROM pg_catalog.pg_database;

But PostgreSQL lets you omit pg_catalog. because it’s in the default search path.

🧬 Examples from pg_catalog


Table/Catalog What it stores

pg_database All databases

pg_tables Tables (more friendly view)

pg_class All tables, indexes, sequences,


etc.

pg_attribute Column definitions

pg_roles Roles (users and groups)

pg_namespac Schemas
e

pg_proc Functions/procedures

🧪 Try This:
-- See all system tables in pg_catalog
SELECT tablename
FROM pg_catalog.pg_tables
WHERE schemaname = 'pg_catalog';

or

-- Show all columns of a specific system table


SELECT *
FROM information_schema.columns
WHERE table_name = 'pg_database';

🟨 Task Example 1 – Create a small database


PRACTICE IN POSGRES…

You might also like