DDL и типы данных

Разберите последствие удаления таблицы, на которую ссылается внешний ключ другой таблицы.

В схеме хранятся таблица и зависящее от неё представление. Какой главный риск создаёт замена RESTRICT на CASCADE в последней команде?

CREATE SCHEMA reporting;

CREATE TABLE reporting.daily_orders (
    order_id INTEGER PRIMARY KEY,
    total DECIMAL(12, 2) NOT NULL
);

CREATE VIEW reporting.recent_orders AS
SELECT order_id, total
FROM reporting.daily_orders;

DROP SCHEMA reporting CASCADE;

От чего зависит, какую таблицу выберет SQL-запрос при обращении к неквалифицированному имени, если одноимённые таблицы находятся в нескольких схемах?

В таблице уже есть данные: при каких условиях добавление обязательного столбца пройдет успешно без предварительного заполнения строк?

Как СУБД проверяет безопасность изменения типа уже заполненного столбца при выполнении DDL?

При подготовке архивной таблицы выполнена команда ниже. Какие ограничения целостности исходной таблицы не гарантирует автоматически сохранить такой способ создания?

CREATE TABLE archive.orders_2024 AS
SELECT order_id, customer_id, total
FROM sales.orders
WHERE created_at < DATE '2025-01-01';

Сравните точный и приближённый числовые типы SQL: почему денежную сумму обычно хранят не в типе с плавающей точкой?

Рассмотрите DDL и две вставки ниже. Почему ограничение UNIQUE допускает обе строки с NULL в email, тогда как PRIMARY KEY не позволяет такое значение?

CREATE TABLE accounts (
    account_id INTEGER PRIMARY KEY,
    email VARCHAR(255) UNIQUE
);

INSERT INTO accounts (account_id, email) VALUES (1, NULL);
INSERT INTO accounts (account_id, email) VALUES (2, NULL);

Какую проблему решает SQL-домен по сравнению с повторением базового типа и одинакового ограничения CHECK в нескольких столбцах?

В сервисе нужно переименовать таблицу, которую использует представление. Предположим, СУБД отслеживает зависимости объектов. Какое ключевое отличие даст ALTER TABLE от удаления таблицы с последующим CREATE TABLE?

CREATE SCHEMA billing;

CREATE TABLE billing.invoice (
    invoice_id INTEGER PRIMARY KEY,
    amount DECIMAL(10, 2) NOT NULL
);

CREATE VIEW billing.open_invoices AS
SELECT invoice_id, amount
FROM billing.invoice;

ALTER TABLE billing.invoice RENAME TO invoice_archive;

Объясните механизм: почему ограничение CHECK может пропустить строку с отсутствующим значением, хотя проверяемое условие для него не выполняется?

В чём принципиальная разница между удалением таблицы и удалением всех строк из неё с точки зрения объектов схемы?

При установке DEFAULT для уже заполненного столбца почему существующие строки не получают это значение?

Определите результат добавления ограничения: какая команда завершится ошибкой и почему?

CREATE TABLE payments (
    payment_id INTEGER PRIMARY KEY,
    amount DECIMAL(10, 2)
);

INSERT INTO payments VALUES (1, 125.00);
INSERT INTO payments VALUES (2, -5.00);

ALTER TABLE payments
ADD CONSTRAINT positive_amount CHECK (amount >= 0);

В проекте нужно хранить только календарную дату. Чем рискован выбор TIMESTAMP вместо DATE?

В каком случае для строкового столбца оправдан CHAR, а не VARCHAR?

В таблице задан тип DECIMAL(5, 2). Предскажите, какая вставка завершится ошибкой из-за диапазона типа, и объясните механизм.

CREATE TABLE prices (
    item_id INTEGER PRIMARY KEY,
    amount DECIMAL(5, 2)
);

INSERT INTO prices VALUES (1, 999.99);
INSERT INTO prices VALUES (2, 1000.00);

Для первичного ключа выбирают между столбцом-идентификатором и отдельной последовательностью: какое различие в управлении объектами определяет выбор?

Чем принципиально различаются TIMESTAMP WITH TIME ZONE и TIMESTAMP WITHOUT TIME ZONE при хранении момента события?

Для производного объекта схемы что определяет выбор между таблицей и представлением: сохраняется ли результат запроса или вычисляется при обращении?