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

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

Способно ли ограничение CHECK гарантировать отсутствие одинаковых значений в разных строках?

Если исходный столбец изменился, почему значение вычисляемого столбца обновляется, а значение столбца с DEFAULT — нет?

При проектировании флага состояния выбрали INTEGER вместо BOOLEAN: какую семантическую гарантию теряет такая модель?

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

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

CREATE SCHEMA ops;

CREATE TABLE ops.source (
    id INTEGER PRIMARY KEY,
    payload TEXT NOT NULL DEFAULT ''
);

CREATE TABLE ops.stage (
    LIKE ops.source INCLUDING ALL
);

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

Представьте большую заполненную таблицу: почему изменение типа столбца иногда выполняется почти мгновенно, а иногда требует переписывания всех строк?

Представьте, что несколько столбцов таблиц используют один SQL-домен. Что произойдет с их проверками после изменения ограничения этого домена?

В миграции взаимосвязанные строки нужно временно вставить в порядке, нарушающем внешний ключ. Какой механизм SQL позволяет отложить проверку ограничения до конца транзакции?