Это, кажется, пропущенная область, которая может действительно использовать некоторое понимание. Каковы ваши лучшие практики для:Как вы управляете обновлениями схемы в производственной базе данных?
и т.д ...
Это отличный вопрос. (Существует большая вероятность, что это закончится нормализованной и денормализованной дискуссией по базам данных, в которую я не собираюсь начинать ... хорошо сейчас для некоторого ввода.)
некоторые с верхней части головы вещи, которые я (добавлю больше, когда у меня есть еще какое-то время или нужно перерыв)
дизайн клиента - здесь метод встроенного SQL-кода (даже с подготовленными инструкциями) позволяет вам попасть в неприятности. Вы можете потратить AGES просто на поиск этих утверждений. Если вы используете что-то вроде Hibernate и помещаете столько SQL в именованные запросы, у вас есть одно место для большей части sql (ничего хуже, чем пытаться протестировать sql, который находится внутри некоторого оператора IF, и вы просто не попадаете в «триггер», критерии в вашем тестировании для этого оператора IF). Прежде чем использовать спящий режим (или другие руны), когда я буду делать SQL непосредственно в JDBC или ODBC, я бы поместил все операторы sql в виде открытых полей объекта (с соглашением об именах) или в файле свойств (также с именованием соглашение для значений, например PREP_STMT_xxxx, и использовать либо отражение, либо итерацию по значениям при запуске в а) тестовых случаях; b) запуск приложения (некоторые rdbms позволяют предварительно компилировать подготовленные операторы перед выполнением, поэтому при запуске после входа в систему I будет предварительно компилировать prep-stmts при запуске, чтобы сделать самотестирование приложения. Даже для 100-х утверждений о хорошем rdbms это всего лишь несколько секунд, и только один раз. И он сохранил мой прикладом много.В одном проекте DBA не будут общаться (другая команда, в другой стране), и схема, казалось, изменилась НОЧЬ, без всякой причины. И каждое утро мы получили список того, где он нарушил приложение, при запуске.
Если вам нужна функциональность adhoc, поместите его в хорошо названный класс (т. Е. Снова соглашение об именах помогает при автоматическом тестировании), которое действует как своего рода завод для вашего запроса (т. Е. Строит запрос). Вам все равно придется писать эквивалентный код, просто введите место, где вы можете его проверить. Вы даже можете написать некоторые базовые методы тестирования на одном и том же объекте или в отдельном классе.
Если вы также можете попробовать использовать хранимые процедуры. Их немного сложнее проверить, как указано выше. Некоторые db также не предварительно проверяют sql в хранимых процедурах против схемы во время компиляции только во время выполнения. Обычно речь идет о том, чтобы взять копию структуры схемы (без данных), а затем создать все сохраненные процедуры против этой копии (в случае, если команда db, внесшая изменения, не проверила корректно). Таким образом, можно проверить структуру. но в качестве точки управления изменениями хранятся procs. Поменять все получится. Особенно, когда изменения db являются результатом изменений бизнес-процесса. И все языки (java, vb и т. Д. Получают изменения)
Обычно я также настраиваю таблицу, которую я использую, называемую system_setting и т. Д. В этой таблице мы сохраняем идентификатор VERSION. Это значит, что клиентские библиотеки могут подключаться и проверять, действительны ли они для этой версии схемы. В зависимости от изменений вашей схемы вы не хотите разрешать клиентам подключаться, если они могут повредить вашу схему (т. Е. У вас нет большого количества ссылочных правил в db, но на клиенте). Это зависит от того, будете ли вы также иметь несколько клиентских версий (что происходит в NON-веб-приложениях, то есть они работают с неправильным двоичным кодом). У вас также могут быть пакетные инструменты и т. Д. Другой подход, который я также сделал, - это определить набор схем для операционных версий в каком-либо файле свойств или снова в таблице system_info. Эта таблица загружается при входе в систему, а затем используется каждым «менеджером» (обычно у меня есть какая-то клиентская сторона api, чтобы делать большую часть материала db), чтобы проверить эту операцию, если она является правильной версией. Таким образом, большинство операций могут преуспеть, но вы также можете провалить (выбросить какое-то исключение) на устаревшие методы и сообщить вам ПОЧЕМУ.
Управление изменением схемы -> обновите таблицу или добавьте отношения 1-1 к новым таблицам? По этой причине я видел много магазинов, которые всегда получают доступ к данным. Это позволяет изменять имена таблиц, столбцы и т. Д. Я играл с идеей фактически обрабатывать представления, такие как интерфейсы в COM. то есть. вы добавляете новый VIEW для новых функций/версий. Зачастую, что вам нужно, так это то, что у вас может быть много отчетов (особенно пользовательских отчетов конечных пользователей), которые принимают форматы таблиц. Представления позволяют развертывать новый формат таблицы, но поддерживают существующие клиентские приложения (помните все эти досадные отчеты adhoc).
Также необходимо написать сценарии обновления и отката. и снова TEST, TEST, TEST ...
------------ OKAY - ЭТО ВРЕМЯ ДИСКУССИОННОГО ВРЕМЕНИ БИТА --------------
На самом деле был большой коммерческий проект (то есть магазин программного обеспечения), где у нас была та же проблема. Архитектура была 2 уровня, и они использовали продукт, немного похожий на PHP, но pre-php. То же самое. другое название. в любом случае я вошел в версию 2 ....
Это стоило МНОГО ДЕНЕГ, чтобы делать обновления. Много. то есть. отдайте недели бесплатного времени на консультацию на месте.
И это доходило до того, что нужно либо добавить новые функции, либо оптимизировать код. Некоторые из существующих кодов использовали хранимые процедуры, поэтому у нас были общие точки, где мы могли управлять кодом. но в других областях была эта встроенная разметка sql в html. Это было здорово для быстрого выхода на рынок, но при каждом взаимодействии новых функций стоимость, по меньшей мере, удваивалась для тестирования и обслуживания.Поэтому, когда мы смотрели на то, чтобы вытащить код типа php, вставляя слои данных (это был 2001-2002, до ORM и т. Д.) И добавляли много новых функций (отзывы клиентов), рассматривали этот вопрос о том, как разрабатывать UPGRADES в систему. Что немаловажно, так как апгрейды стоят много денег, чтобы делать правильно. Теперь большинство моделей и все другие вещи, которые люди обсуждают со степенью энергии, имеют дело с OO-кодом, который работает, но как насчет того факта, что ваши данные должны: a) интегрироваться в эту логику, b) значение, а также структуру данные могут меняться со временем, а часто из-за того, как работают данные, вы получаете множество подпроцессов/приложений в организации ваших клиентов, которым нужны эти данные -> специальная отчетность или любая сложная пользовательская отчетность, а также пакетные задания которые были сделаны для пользовательских каналов данных и т. д.
Учитывая это, я начал играть с чем-то, что осталось от поля. В нем также есть несколько предположений. а) данные сильно читаются больше, чем записываются. б) обновления происходят, но не на уровне банков, т.е. один или 2 секунды говорят.
Идея заключалась в том, чтобы применить представление COM/Interface к тому, как клиенты получали доступ к данным через набор таблиц CONCRETE (которые менялись с изменениями схемы). Вы можете создать отдельное представление для каждой операции типа - обновить, удалить, вставить и прочитать. Это важно. Представления будут либо сопоставляться непосредственно с таблицей, либо позволять вам запускать фиктивную таблицу, которая делает реальные обновления или вставки и т. Д. То, что я действительно хотел, было какой-то косвенной степенью косвенности, которую все еще можно было использовать в отчетах о кристаллах и т. Д. ПРИМЕЧАНИЕ. - Для вставок, обновления и удаления вы также можете использовать сохраненные procs. И у вас была версия для каждой версии продукта. Таким образом, у вашей версии 1.0 была своя версия схемы, и если бы таблицы были изменены, у вас все равно была бы версия VIEWS версии 1.0, но с новой логикой backend для сопоставления с новыми таблицами по мере необходимости, но у вас также были представления версии 2.0, которые поддерживали бы новые поля и т. д. Это было действительно просто для поддержки специальных отчетов, которые, если ваш человек BUSINESS, а не кодер, вероятно, весь смысл того, почему у вас есть продукт. (ваш продукт может быть дерьмом, но если у вас есть лучшая отчетность в мире, которую вы все равно можете выиграть, обратное верно - ваш продукт может быть лучшей особенностью мудрый, но если его хуже при отчетности, вы можете очень легко потерять).
ОК, надеюсь, что некоторые из этих идей помогут.
Как это получило принятый ответ? Как он отвечает на вопросы в исходном вопросе? –
Этот ответ даже связан с вопросом? –
В общем, мое правило гласит: «Приложение должно управлять своей собственной схемой».
Это означает, что сценарии обновления схемы являются частью любого пакета обновления для приложения и запускаются автоматически при запуске приложения. В случае ошибок приложение не запускается и транзакция сценария обновления не выполняется. Недостатком этого является то, что приложение должно иметь полный доступ к модификации схемы (это раздражает администраторов баз данных).
У меня был большой успех с использованием функции Hibernates SchemaUpdate для управления структурами таблиц. Оставляя сценарии обновления только для обработки фактической инициализации данных и случайного удаления столбцов (SchemaUpdate этого не делает).
Что касается тестирования, так как обновления являются частью приложения, тестирование их становится частью цикла тестирования для приложения.
Дополнительная информация: Принимая на борту некоторые из критических замечаний в других сообщениях здесь, обратите внимание, что правило гласит: «Это собственное». Это применимо только там, где приложение принадлежит схеме, как это обычно бывает в случае программного обеспечения, продаваемого в качестве продукта. Если ваше программное обеспечение использует базу данных с другим программным обеспечением, используйте другие методы.
Я большой поклонник Red Gate продуктов, которые помогают создавать пакеты SQL для обновления схем баз данных. Сценарии базы данных могут быть добавлены в исходный элемент управления, чтобы помочь в управлении версиями и откате.
Это все веские темы, но вот моя рекомендация по обновлению.
Вы не указали свою платформу, но для систем построения NANT я использую Tarantino. Для каждого обновления базы данных, которое вы готовы совершить, вы создаете сценарий изменений (используя RedGate или другой инструмент). Когда вы создаете для производства, Tarantino проверяет, запущен ли сценарий в базе данных (он добавляет таблицу в вашу базу данных для отслеживания). Если нет, сценарий запускается. Из управления версиями базы данных требуется вся ручная работа (читай: человеческая ошибка).
liquibase.org:
[Flyway] (https://flywaydb.org) - еще один выбор, похожий по своим намерениям на Liquibase: миграция базы данных упростилась, позволяя вам развивать вашу схему. Flyway построен на Java, предназначен для использования с Java, но также может быть вызван из командной строки. Как Liquibase, так и Flyway, похоже, являются хорошо продуманными проектами. –
мнение
приложение должно никогда обрабатывать обновления схемы. Это катастрофа в ожидании. Данные превосходят приложения, и как только несколько приложений пытаются работать с одними и теми же данными (например, производственное приложение + приложение для отчетов), скорее всего, они будут использовать одни и те же базовые библиотеки компаний ... и затем обе программы сделать свое собственное обновление db ... весело провести время с , что беспорядок.
Я слышал хорошие вещи о iBATIS 3 Schema Migrations System: Руководство
Пользователь: http://svn.apache.org/repos/asf/ibatis/java/ibatis-3/trunk/doc/en/iBATIS-3-Migrations.pdf
Как сказал Пэт, использование LiquiBase. Особенно, когда у вас есть несколько разработчиков со своими собственными базами данных , внося изменения, которые станут частью производственной базы данных.
Если есть только один разработчик, как в одном проекте, я сейчас (га), я просто передаю изменения схемы как текстовые файлы SQL в репозиторий CVS, которые я проверяю партиями на производственном сервере, когда изменения кода вступают.
Но Liquibase лучше организована, чем это!
Я удивлен, что здесь не так много ответов - возможно, нужны специальные теги oracle или sqlserver? –
хорошая идея, спасибо! –