В сервисе нужно переименовать таблицу, которую использует представление. Предположим, СУБД отслеживает зависимости объектов. Какое ключевое отличие даст 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;
ALTER TABLE ... RENAME TO изменяет имя существующего объекта, поэтому таблица сохраняет свою идентичность, данные, ограничения и обычно связанные зависимости. Представление продолжает ссылаться на ту же таблицу, хотя обращаться к ней напрямую теперь нужно по новому имени.
Удаление с последующим созданием формирует уже другой объект: данные и ограничения пришлось бы восстанавливать отдельно, а зависимости, права и служебные связи могли бы исчезнуть или потребовать повторной настройки.
Имена таблиц и других объектов схемы используются не только в тексте SQL-запросов. СУБД хранит в системном каталоге сами объекты, их атрибуты, ограничения, права и зависимости между ними.
Поэтому DDL разделяет изменение свойства существующего объекта, например его имени, и уничтожение объекта. Такой подход позволяет проводить структурные изменения без имитации операции через удаление и повторное создание.
Если заменить переименование последовательностью DROP TABLE и CREATE TABLE, между операциями может исчезнуть исходная таблица. Это создает риск потери данных, ограничений, индексов, выданных прав и зависимых объектов.
Даже если затем создать таблицу с тем же именем и столбцами, это будет новый объект. Совпадение имени и структуры не означает сохранения внутренней идентичности или всех метаданных.
Команда ALTER TABLE ... RENAME TO меняет имя записи таблицы в системном каталоге. Она не меняет тип столбцов, строки, первичный ключ или ограничение NOT NULL.
В примере представление billing.open_invoices зависит от таблицы как от объекта. В СУБД с поддержкой зависимостей эта связь сохраняется, поэтому представление продолжает работать после переименования. При этом старое квалифицированное имя billing.invoice больше не является именем таблицы, а новое имя — billing.invoice_archive — становится ее адресом.
Переименование не гарантирует отсутствие всех последствий. Приложение, хранимая процедура или динамически сформированный SQL, где имя таблицы записано обычным текстом, может продолжить обращаться к старому имени и завершиться ошибкой. Точный способ хранения зависимостей, поведение процедур и синтаксис переименования зависят от конкретной СУБД.
Переименование также может блокировать таблицу на время изменения системного каталога. Поэтому в рабочей системе нужно учитывать конкурирующие запросы, длительность блокировок и порядок развертывания приложения.
Первый запрос по-прежнему использует представление, а второй обращается к таблице по новому имени. Операция переименования предпочтительнее пересоздания, когда требуется сохранить объект и его метаданные, но она не заменяет проверку клиентского кода и миграционных зависимостей.
Команда хочет переименовать billing.invoice в billing.invoice_archive, не меняя состав данных. Были рассмотрены два варианта.
Удалить и создать заново можно использовать, если таблица полностью пересобирается из резервной копии или миграционного источника. Но вариант требует отдельно переносить строки, индексы, ограничения, права и зависимости; при ошибке возможны потеря данных и недоступность представлений.
Переименовать существующую таблицу быстрее и сохраняет объектные связи, но старое имя сразу перестает работать для клиентов, которые формируют SQL напрямую. Поэтому выбран второй вариант: сначала выпущена версия приложения, способная работать с новым именем, затем выполнено переименование в контролируемом окне и проверены представления, процедуры и права.
В результате данные и зависимости сохранились, а риск отказа был ограничен предварительной проверкой обращений к старому имени.
В СУБД, которая отслеживает зависимости объектов, представление обычно продолжает ссылаться на прежний объект, а не на строку с его старым именем. Поэтому его текстовая форма может быть автоматически обновлена, нормализована или отображаться иначе — это уже зависит от СУБД. Существенный результат один: зависимость от самой таблицы сохраняется, а не превращается в ссылку на несуществующее старое имя.
Поскольку переименование изменяет имя существующего объекта, права обычно остаются связанными с этим объектом. Но это не универсальная гарантия для всех СУБД и всех механизмов авторизации: могут существовать отдельные правила для синонимов, ролей, политик безопасности или внешних каталогов. На практике права нужно проверить в целевой СУБД после миграции, а не выводить их поведение только из имени таблицы.
Само переименование старое имя не сохраняет. Возможные решения — сначала обновить клиентов, создать совместимый слой с прежним именем, например представление, или использовать версионирование схемы и поэтапную миграцию.
Совместимое представление может помочь для операций чтения, но не всегда заменяет таблицу для вставок, обновлений, триггеров и специфичных возможностей СУБД. Поэтому выбор зависит от характера запросов и от того, нужен ли старым клиентам полный интерфейс таблицы.