Каковы лучшие практики удаления устаревших столбцов базы данных? [закрыто]

Я разрабатываю приложение, которое на ранней стадии будет собирать данные A, B и C от клиентов, но позже вместо этого будет собирать данные A, B и D.

A, B, C и D очень связаны и в настоящее время существуют в виде столбцов одной таблицы T базы данных PostgreSQL .

Как только C больше не нужен, я хочу удалить его ссылки из моего приложения (я использую Django ORM ), но я хочу сохранить данные, которые уже были введены. Каков наилучший способ сделать это?

Я думал о создании новой таблицы для ABD, но это означает, что это может вызвать проблемы с любыми строками, ссылающимися на таблицу T.

Я мог бы просто оставить столбец C и удалить ссылки на него в коде, что позволило бы существующим данным выжить.

Есть ли лучший вариант, которого я не вижу?

Некоторые дополнительные детали:

Количество строк не будет большим, скорее всего, 1-2 на пользователя. Это приложение для массового рынка, но к тому времени, когда я переключусь с C на D, база пользователей будет еще не очень большой. С и D, скорее всего, не будут собираться одновременно, хотя это возможно. C и D, вероятно, представляют собой несколько столбцов, а не только один.

Если вы хотите сохранить данные, то они не устарели. Просто оставь это там, где оно есть. Хорошо, если какой-то класс, сопоставленный с таблицей, не отображает каждый столбец.

Итак, ваша ситуация такова, что вы хотите, чтобы старые строки имели свойство C, а новые - нет.

Это эквивалентно наличию наследственных отношений класса

class All
{
    string A;
    string B;
}

class Old : All
{
    string C;
}

class New : All
{
    string D;
}

который вы представляете в базе данных с тремя таблицами с отношениями 1: 1

table All
    id varchar
    A varchar
    B varchar

table Old
    id varchar
    C  varchar

table New
    id varchar
    D  varchar

Таким образом, вы можете создать сценарий миграции для создания новой старой таблицы, скопировать в нее данные id и C и удалить столбец C из таблицы All.

Обновление вашего кода в соответствии с требованиями нового sql;

В качестве альтернативы, если вам просто нужно иметь возможность запрашивать старые данные C, вы можете создать новую таблицу Archive с A, B, C, скопировать все данные и удалить столбец C, добавьте D col в вашу таблицу 'Live'

Если хранение данных может быть проблемой, то разделите таблицы: ключ / A / B ключ / C ключ / D

Вы можете получить доступ либо через представление (определение местоположения данных в БД), либо изменив определение ORM.

Это не самый эффективный (включается объединение), но он может представлять любую комбинацию A / B / C / D с течением времени без изменения базового хранилища, и в зависимости от ваших реальных схем доступа этого может быть достаточно.

Вам может не повезти с возможностью проводить простои, реструктурировать таблицы и т. Д. В производственной системе.

Выполнение доступа через представление позволяет переключаться с A / B / C на A / B / C / D на A / B / D в базовой таблице с минимальными изменениями и без перемещения данных. Представление будет прозрачным для логики чтения, и если ваша база данных поддерживает либо функции, либо обновляемые представления, то также прозрачно для логики записи.

Действительно, я думаю, что ваше решение отразит множество реальных проблем: 1) что такое типы данных C & D 2) относительные объемы данных, собранные для C / D 3) относительное перекрытие данных C / D по сравнению с чисто записями C или D 4) Доступность и продолжительность окна простоя / обслуживания 5) Поддержка СУБД для обновляемых представлений 6) Желательность сохранения деталей физической структуры БД в ORM против их прозрачности путем представления через представления / функции в БД (где она одинакова для всех обращающихся приложения, а не только текущее)

Мой ответ предпочтителен для больших / сложных типов данных для (1), небольшого перекрытия для (3) и минимального времени простоя для (4), в идеале с хорошей поддержкой dbms в (5) и множественных приложений, обращающихся к данным в (6)

Но для многих альтернатив нет правильного / неправильного: - начать с A / B / C, затем добавить D, настроить ORM, еще позже удалить столбец C - начать с A / B / C / D и игнорировать нули и т. Д. Я думаю, рассмотрите свое решение и то, что вы знаете о его предполагаемом назначении / жизненном цикле, проведите некоторое моделирование размера / объема и ожидайте, что все изменится позже, поскольку не все изменится так, как ожидалось.

Удаление ссылок и потеря данных - это вариант с низким риском.

Всегда возможны неизвестные «закулисные» способы использования данных, которые могут или не могут быть важны для раскрытия путем удаления столбца.

В зависимости от содержимого столбца C может возникнуть небольшая проблема с производительностью, когда внутренняя БД выполняет полное сканирование таблицы или пытается извлечь всю таблицу в память во время объединений, если оптимизатор считает это более эффективным, чем использование индексов.

Приложения могут читать всю таблицу несколько раз, а не выбранные столбцы, но если вы используете исключительно ORM, это маловероятно.

Здесь нужно учитывать много вещей, но вы можете рассмотреть возможность добавления представления для наложения таблицы, а не внесения изменений в таблицу напрямую. Таким образом, нужно изменить только представление.

Я не знаю Django ORM, но это возможно.

• У вас есть таблица A с колонками a, b, c.
• Создайте новую таблицу B со столбцами a, b, d.
• Перенесите ваши данные в таблицу B.
• Переместите свои внешние ключи в таблицу A в таблицу B.

Теперь вы можете использовать Таблицу B, и у вас все еще есть старые данные для справки.