Доработка базы как правильно поступить???

← →
Андрей Пл (2007-12-25 17:19) [0]

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

← →
Andrey © (2007-12-25 17:24) [1]

Все изменения которые ты вносишь в дорабатываемую базу складывать в отдельный скрипт.
Потом приходишь к заказчику, бекапишь базу, накатываешь на нее обновляющий скрипт, тестишь ничего ли не порушилось. Если всё гут - всё гут, если не всё - ищешь где напортачил.

← →
kaif © (2007-12-25 17:26) [2]

Я в таких случаях пишу специальное (для себя) приложение для перекачки данных из старой базы в новую. Дельфи для таких задач - превосходный инструмент.

← →
Kolan © (2007-12-25 17:26) [3]

> [1] Andrey © (25.12.07 17:24)

Только перед этим надо сделать бэк ап&#133

← →
Andrey © (2007-12-25 17:32) [4]

>Kolan ©
Вторая строка, 5-6 слово )

← →
Kolan © (2007-12-25 17:43) [5]

> Вторая строка, 5-6 слово )

Да проглядел&#133

Кроме того скрипты хорошо собирать, чтобы если ты сделал два апгрйеда(0 > 1 > 2, цифры  версии БД), то всегда была возможность проапгрейдить как базу в версии 0 так и в версии 1.

← →
Sergey13 © (2007-12-26 10:00) [6]

> [2] kaif © (25.12.07 17:26)

Такое, ИМХО, пройдет только для небольших и несложных баз. Кроме того желательно быть автором этой БД. Иначе вероятность, что что-то пропустил и не скопировал очень велика.

+ к
> [1] Andrey © (25.12.07 17:24)

Существует масса инструментов для разных СУБД, генерирующих такой скрипт автоматом.

← →
Desdechado © (2007-12-26 11:20) [7]

> Существует масса инструментов для разных СУБД, генерирующих
> такой скрипт автоматом.
Э-э, тут важна последовательность применения изменений. Особенно при наличии данных в БД, чтоб все сохранилось и не вступало в противоречие друг с другом. Не видел такой автоматики.

← →
Sergey13 © (2007-12-26 11:39) [8]

> [7] Desdechado © (26.12.07 11:20)

Получить скрипт различий 2 баз можно автоматически. Про автоматически его применять на боевой БД я не писал. 8-)
Зато такие инструменты ничего не забывают.

← →
Desdechado © (2007-12-26 12:25) [9]

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

← →
Sergey13 © (2007-12-26 12:37) [10]

> [9] Desdechado © (26.12.07 12:25)

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

Могу рассказать, как делается модификация структуры ядра базы данных в моей системе Allegro, к примеру. Имеется таблица с одной строкой, в которой лежит номер "версии ядра". Ядром называются системные таблицы Allegro (дело в том, что там еще имеются и пользовательские таблицы и таких очень много). Когда Allegro обращается к базе данных, оно смотрит номер "версии ядра". Если этот номер 9, а текущий номер версии Allegro 12, то вызывается некая DbUpdate.dll, которая последовательно применяет преобразования 9->10, 10->11, 11->12. Каждое преобразование состоит из ряда SQL-команд (плюс иногда некоторого программного кода). То есть в моей DbUpdate.dll имеется функция "кумулятивного апдейта"

boolean UpdateDbVersion(FromVersion, ToVersion: integer);

которая последовательно вызывает функции типа:

boolean UpdateDbVersion9_10;
boolean UpdateDbVersion10_11;
boolean UpdateDbVersion11_12;
...
----------------------------
После релиза очередной версии, я больше не трогаю ни одну функцию. Если где-то была ошибка, исправляю в следующей версии (12->13).
----------------------------
Собственно, важно лишь одно: не забывать, какие изменения уже были применены к базе, а какие еще нет.

Поэтому рекомендую ввести номер версии в базу данных.
Мало ли?
Вдруг еще придется что-то менять.

Это особенно актуально, если у разных пользователях на руках могут оказаться разные версии одной и той же базы данных, а последняя версия приложения может работать только с последней версией и нужно у всех как-то обновить структуру всех баз.

Не знаю, имеет ли смысл говорить о версии, если база всего одна. Но не исключено, что имеет смысл даже в этом случае. Мало ли? Бекапы тоже могут быть разной давности. А вдруг какой-то из них понадобится?

Не знаю, понятно ли объяснил идею последовательных апдейтов с нумерацией версий...

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

очень полезный совет, неоднократно провереный на моем опыте.

> kaif © (26.12.07 15:29) [11]
У нас аналогично, вроде, за исключением того, что программа апдейтер ничего не знает о структуре БД, кроме таблицы с версиями и таблицы с пакетами обновления. При обнаружении очережного обновления она загоняет его в БД в блоб, а потом последовательно выполняет скрипты из него, даже если нужно переконнектиться, просто запоминается в БД, какие SQL уже выполнены, а с какого нужно продолжить. После окончания выполнения пакета устанавливается очередная цифра в таблицу версий.

У меня была ситуация немного сложнее. Начальство очень сильно прогибалось под заказчиков и если заказчики требовали какой-то функционал завтра, он должен был у них появиться завтра. При этом баз было не 1 и не 2, а около 20-25. Биллинг для мелки операторов (телефония и инет) это был.

Как делали мы. Команда из 4 человек. Мы выпускали официальные апдейты базы и клиента примерно раз в 2-3 месяца.

Был каталог в котором лежал полный скрипт меняющий структуру базы из версии, допустим, 2 в 3. На основании его формировался апдейт. Ну вобщем дальше всё как обычно, тесты, хотфиксы, крики, маты, хотфиксы -> готовый апдейт который можно применить к базе клиента для перевода ее из версии 2 в 3... короче пормальная рабочая обстановка.

Про прогибающееся начальство и версию базы 2+.
Как я говорил, "если заказчики требовали какой-то функционал завтра, он должен был у них появиться завтра". И он обычно появлялся. Как это достигалось: в файлы со скриптом апдейта мы выкладывали цельные логические блоки скрипта (допустим включение фастрепорта было оформлено в создание 2-3 таблиц ну и еще по мелочи, и в скрипте оно появилось цельным куском, когда было закончено и оттестировано разработчиком).
Плюс ко всему эти блоки всегда были безопасны для многоразового применения. Тоесть прогнав один и тот же блок 2 раза нельзя было испортить логику базы. Да, иногда для этого надо было писать дополнительный код типа запросов к системным таблицам и т.д., но таков был корпоратывный стандарт. Чисто информативно мы в скрипте иногда ставили пометки типа:
------- ^^^ Дядя Вася
Сие значило, что до сего момента скрипт был накачен дяде васе и если он еще захочет чего-то странного до апдейта, можно накатывать только то что идет ниже.
С клиентским местом было примерно так же. Собирался последний билд на текущий момент, его и отдавали заказчику. Без жесткого тестирования.

Конечно в результате общая надежность системы падала хотябы потому что "написать" и "написать и оттестировать" это сильно разные вещи, но это лучшее что мы изобрели для "мгновенного" введения фунуционала.

Мне, как разработчику такая схема не по душе... Но если она есть и приносит не кислый доход, почему бы и нет )

Доработка базы как правильно поступить??? Найти похожие ветки