При

liquibase.org:

1. он понимает hibernate определения.
2. он генерирует лучшее обновление схемы sql, чем hibernate
3. он регистрирует, какие обновления были сделаны в базе данных
4. он обрабатывает двухэтапные изменения (например, удаляет столбец "foo", а затем переименовывает другой столбец в "foo")
5. он обрабатывает концепцию условных обновлений
6. разработчик на самом деле слушает сообщество (с hibernate, если вы не находитесь в толпе "in" или новичок-вы в основном игнорируетесь.)

http://www.liquibase.org

мнение

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

В общем мое правило таково: "The application should manage it's own schema."

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

Я добился большого успеха, используя функцию Hibernates SchemaUpdate для управления структурами таблиц. Оставляя скрипты обновления только для обработки фактической инициализации данных и случайного удаления столбцов (SchemaUpdate этого не делает).

Что касается тестирования, поскольку обновления являются частью приложения, тестирование их становится частью цикла тестирования для приложения.

Запоздалая мысль: принимая во внимание некоторую критику в других постах здесь, обратите внимание, что правило говорит "it's own". Это действительно применимо только там, где приложение владеет схемой, как это обычно бывает с программным обеспечением, продаваемым как продукт. Если ваше программное обеспечение совместно использует базу данных с другим программным обеспечением, используйте другие методы.

Я большой поклонник продуктов Red Gate , которые помогают создавать пакеты SQL для обновления схем баз данных. Сценарии базы данных могут быть добавлены в систему управления версиями, чтобы помочь в управлении версиями и откате.

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

кое-что из того, что я уже сделал (добавлю еще, когда у меня будет больше времени или мне понадобится перерыв)

клиентский дизайн-это то, где метод VB встроенного sql (даже с подготовленными инструкциями) вызывает у вас проблемы. Вы можете потратить AGES только на поиск этих утверждений. Если вы используете что-то вроде Hibernate и помещаете столько же SQL в именованные запросы, у вас есть одно место для большинства sql (ничего хуже, чем пытаться проверить sql, который находится внутри некоторого оператора IF, и вы просто не попадаете в критерии "trigger" при тестировании для этого оператора IF). Перед использованием hibernate (или других orms), когда я буду делать SQL непосредственно в JDBC или ODBC, я помещу все операторы sql либо в открытые поля объекта (с Соглашением об именовании), либо в файл свойств (также с Соглашением об именовании для значений, скажем PREP_STMT_xxxx. И используйте либо отражение, либо повторение значений при запуске в а) тестовых случаях б)запуске приложения (некоторые rdbms позволяют предварительно скомпилировать подготовленные инструкции перед выполнением, поэтому при запуске после входа в систему я бы предварительно скомпилировал prep-stmts при запуске, чтобы сделать самотестирование приложения. Даже для 100-х высказываний на хорошем rdbms это всего лишь несколько секунд. и только один раз. И это во многом спасло мою задницу. В одном проекте DBA-е не общались (другая команда, в другой стране), и схема, казалось, изменилась NIGHTLY, без всякой причины. И каждое утро мы получали список того, где именно сломалось приложение, при запуске.

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

Если вы можете, также попробуйте использовать хранимые процедуры. Их немного сложнее проверить, как описано выше. Некоторые БД также не выполняют предварительную проверку sql в хранимых процедурах по отношению к схеме во время компиляции только во время выполнения. Это обычно включает в себя, скажем, создание копии структуры схемы (без данных), а затем создание всех хранимых процессов против этой копии (в случае, если команда БД, вносящая изменения DIDn, не проверяет корректно). Таким образом, структура может быть проверена. но с точки зрения управления изменениями хранимые процессы очень хороши. На перемене все это получают. Особенно если изменения БД являются результатом изменений бизнес-процессов. И на всех языках (java, ВБ и т. д. изменения )

Обычно я также настраиваю таблицу, которую использую, называемую system_setting и т. д. В этой таблице мы сохраняем идентификатор VERSION. Это делается для того, чтобы клиентские библиотеки могли подключаться и проверять, являются ли они допустимыми для этой версии схемы. В зависимости от изменений в вашей схеме вы не хотите разрешать клиентам подключаться, если они могут повредить вашу схему (т. е. у вас не так много ссылочных правил в БД, но на клиенте). Это зависит от того, будет ли у вас также несколько клиентских версий (что происходит в NON - web apps, ie. они запускают неверный двоичный файл). Вы также можете иметь пакетные инструменты и т. д. Другой подход, который я также сделал, заключается в определении набора схем для версий операций в некотором файле свойств или снова в таблице system_info. Эта таблица загружается при входе в систему, а затем используется каждым "manager" (у меня обычно есть какая-то клиентская сторона api, чтобы делать большинство вещей БД) для проверки этой операции, если это правильная версия. Таким образом, большинство операций могут быть успешными, но вы также можете потерпеть неудачу (создать некоторое исключение) на устаревших методах и сообщить вам WHY.

управление изменением схемы - > вы обновляете таблицу или добавляете отношения 1-1 в новые таблицы ? Я видел много магазинов, которые всегда получают доступ к данным через представление по этой причине. Это позволяет изменять имена таблиц, столбцов и т.д. Я играл с идеей на самом деле рассматривать представления как интерфейсы в COM. т.е.. вы добавляете новый VIEW для новых функций / версий. Часто вы получаете здесь то, что у вас может быть много отчетов (особенно пользовательских отчетов конечных пользователей), которые предполагают табличные форматы. Представления позволяют развернуть новый формат таблицы, но поддерживают существующие клиентские приложения (помните все эти надоедливые отчеты adhoc).

Кроме того, необходимо написать сценарии обновления и отката. и снова TEST, TEST, TEST...

------------ OKAY-ЭТО НЕМНОГО СЛУЧАЙНОЕ ВРЕМЯ ОБСУЖДЕНИЯ --------------

На самом деле был большой коммерческий проект (т. е. магазин программного обеспечения), где у нас была та же проблема. Архитектура была двухуровневой, и они использовали продукт немного похожий на PHP, но до php. То же самое. разные имена. во всяком случае, я пришел в версии 2....

Это стоило больших денег, чтобы сделать модернизацию. Много. т.е.. дайте несколько недель свободного времени для консультаций на месте.

И дело дошло до того, что ему захотелось либо добавить новые функции, либо оптимизировать код. В некоторых существующих кодах используются хранимые процедуры, поэтому у нас есть общие точки, где мы можем управлять кодом. но другие области были таким образом встроены sql markup в html. Это было здорово для быстрого выхода на рынок, но с каждым взаимодействием новых функций стоимость тестирования и обслуживания по меньшей мере удваивалась. Поэтому, когда мы рассматривали вытаскивание кода типа php, размещение слоев данных (это было в 2001-2002 годах, до любого ORM и т. д.) и добавление большого количества новых функций (обратная связь с клиентами), мы рассматривали этот вопрос о том, как проектировать UPGRADES в систему. Что очень важно, так как обновление стоит больших денег, чтобы сделать это правильно. Так вот, большинство шаблонов и все остальные вещи люди обсудите с определенной долей энергии дело с OO кодом, который работает, но как насчет того, что ваши данные должны а) интегрироваться в эту логику, б) смысл и структура данных могут изменяться с течением времени, и часто из-за того, как данные работают, вы в конечном итоге получаете много подпроцессов / приложений в вашей организации клиентов, которым нужны эти данные - > специальные отчеты или любые сложные пользовательские отчеты, а также пакетные задания, которые были сделаны для пользовательских каналов данных и т. д.

Имея это в виду, я начал играть с чем-то немного левее поля. У него также есть несколько предположений. а) данные в значительной степени читаются больше, чем пишутся. б) обновления действительно происходят, но не на уровне банков ie. один или 2 в секунду говорят.

Идея состояла в том, чтобы применить представление COM / Interface к тому, как клиенты получают доступ к данным через набор таблиц CONCRETE (которые изменялись с изменением схемы). Вы можете создать отдельный вид для каждой операции типа - обновление, удаление, вставка и чтение. Это очень важно. Представления будут либо непосредственно сопоставлены с таблицей, либо позволят вам запустить фиктивную таблицу, которая выполняет реальные обновления или вставки и т. д. То, что я на самом деле хотел, было своего рода уловимым уровнем косвенности, который все еще мог быть использован crystal reports и т. д. NOTE - для вставки , обновления и удаления также можно использовать хранимые процедуры. И у вас была версия для каждой версии продукта. Таким образом, ваша версия 1.0 имела свою версию схемы, и если бы таблицы изменились, у вас все равно была бы версия 1.0 VIEWS, но с логикой NEW backend для сопоставления с новыми таблицами по мере необходимости, но у вас также были бы представления версии 2.0, которые поддерживали бы новые поля и т. д. Это было действительно просто для поддержки специальной отчетности, которая, если ваш человек a BUSINESS, а не кодер, вероятно, вся суть в том, почему у вас есть продукт. (ваш продукт может быть дерьмовым, но если у вас есть лучшая отчетность в мире, вы все равно можете выиграть, верно обратное - ваш продукт может быть лучшим по характеристикам, но если он хуже по отчетности, вы можете очень легко потерять).

ладно, надеюсь, некоторые из этих идей помогут.

Это все весомые темы, но вот моя рекомендация по обновлению.

Вы не указали свою платформу, но для NANT сборочных сред я использую Tarantino . Для каждого обновления базы данных, которое вы готовы зафиксировать, вы делаете сценарий изменения (используя RedGate или другой инструмент). При сборке в производство Tarantino проверяет, был ли сценарий запущен в базе данных (он добавляет таблицу в вашу базу данных для отслеживания). Если нет, то скрипт запускается. Это отнимает всю ручную работу (читай: человеческая ошибка) от управления версиями баз данных.

Я слышал много хорошего о системе миграции схем iBATIS 3 :

Руководство Пользователя: http://svn.apache.org/repos/asf/ibatis/java/ibatis-3/trunk/doc/en/iBATIS-3-Migrations.pdf

Как сказал Пэт, использовать при. Особенно если у вас есть несколько разработчиков со своими собственными базами данных dev внесение изменений, которые станут частью производственной базы данных.

Если есть только один dev, как в одном проекте, над которым я сейчас работаю (ha), я просто фиксирую изменения схемы в виде SQL текстовых файлов в CVS repo, которые я проверяю пакетами на производственном сервере, когда изменения кода поступают.

Но liquibase лучше организована, чем это!