назад совместимые базы данных изменения

Question

У меня было обсуждение с нашим администратором базы данных о том, как изменить схему базы данных. Его мнение состоит в том, что все изменения должны быть обратимыми. Например:

• Устаревшие таблицы/столбцы не следует отбрасывать, как только они становятся излишними. Вместо этого они должны храниться как минимум для нескольких выпусков.
• Вместо того, чтобы переименовывать таблицу/столбец, создайте новую таблицу/столбец и скопируйте содержимое из старого в новый.
• Когда необходимо сохранить сохраненный proc/trigger с именем 'foo', оставьте исходную сохраненную процедуру/trigger на месте и создать новый хранимый proc/trigger с именем 'foo2'. Конечно, это означает, что все ссылки на хранимый proc/trigger необходимо обновить, чтобы ссылаться на новое имя

Преимущество этого подхода состоит в том, что база данных может быть переключена на предыдущую версию, если (например) выпуск выходит из строя, и нужно вернуться к предыдущей версии приложения. Это было бы невозможно, если бы таблицы и столбцы были просто удалены.

У меня есть свое мнение о мудрости этого подхода, но я буду держать их в покое, опасаясь смещения ответов. В случае, если это имеет какое-то значение, среда - это стартап, создающий приложение для социальной сети.

Answer 1

Вы не говорите, в какой среде программного обеспечения вы находитесь, кроме как с предпринимательской (банковской) работы, это мои взгляды.

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

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

Возможно, дубликат базы данных, сделанный в момент выпуска, может быть обновлен новыми данными, но среда может не позволить этого (хотя это основной способ, которым я делал большие выпуски).

По моему опыту проблема выпуска может повлиять на одну небольшую часть системы, и большая часть ее в порядке, поэтому вы не хотите закрывать и возвращать всю систему, чтобы восстановить небольшую часть.

Однако, учитывая, что изменения должны быть обратимыми, я думаю, что ваш dba немного консервативен.

Таблицы и столбцы должны быть отброшены на каком-то этапе, но это может подождать до более поздней версии, чтобы вы могли вернуться назад

Да всегда копировать данные (на самом деле, вероятно, лучше не переименовывать, как если имя не является полностью неодобрительно рисковать делать изменения, конечно, издержки на какую-либо выгоду). Если тип столбца должен быть изменен, он зависит от сервера SQL и того, что делается. Для примера в Sybase я бы позволил увеличить размер столбца, поскольку это не изменяет данные, но для уменьшения размера потребуется копирование, поскольку данные могут быть затронуты.

Что касается хранимых процедур и триггеров, я бы не стал переименовывать и просто перезаписывать, поскольку это похоже на скомпилированный код. Объект, который вы изменяете, не зависит от данных и поэтому может быть воссоздан немедленно. Хотя это предполагает, что yo может легко получить любую предыдущую версию хранимой процедуры из управления версиями и т. Д.(Я видел dbs, где код не находится под управлением версиями, и единственная версия находится в db, а затем я вижу необходимость не перезаписывать код - но я бы получил код под контролем до следующей версии)

Answer 2

Похоже, DBA слишком ленив, чтобы делать резервные копии. ;)

Answer 3

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

Сделайте резервную копию базы данных, а затем создайте свои моды. Если что-то произойдет, вернитесь к своей резервной копии.

Хранение всего в базе данных все время приведет к невероятному раздуванию. Не только это, вы можете получить некоторые проблемы с производительностью. И САМЫЙ ВАЖНО, позже никто не захочет прикоснуться к нему, так как они не будут знать, почему он там. В отличие от кода, сложнее выяснить, почему в базе данных есть дополнительные столбцы и т. Д. В будущем. Они не будут знать, что это устаревшие данные/код, и поэтому они просто будут поддерживать его!

Answer 4

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

И он также сохраняет ограничения, которые регулируют те столбцы, которые он не хочет сразу бросать?

Смысл того, что сбои обновления могут возникнуть из-за ограничений, которые пользователь объявил, больше не являются частью бизнес-правил?

Я сочувствую людям, которые последовательно стремятся «постепенно и осторожно« постепенно прекратить ». Я просто не знаю, поддерживается ли этот подход в контексте базы данных во всех приведенных вами примерах.