Динамическое исправление баз данных

Question

Пожалуйста, прости мой длинный вопрос. У меня есть идея дизайна, который я мог бы использовать некоторые комментарии Это хорошая идея сделать это? И о каких ямах я должен знать? Есть ли другие подобные реализации, которые лучше?

Моя ситуация выглядит следующим образом:
Я работаю над переписыванием приложения Windows Forms, которое подключается к серверу SQL 2008 (ранее это был SQL 2005). Приложение представляет собой «экспертную систему» ​​для инжиниринговой компании, где мы храним структурированные данные о конструкциях. Мы контролируем все установки клиентского программного обеспечения, у нас нет внешних клиентов или пользователей, все они являются внутренними для компании, и им всем доверяют, чтобы они не сделали ничего вредоносного для программного обеспечения или базы данных.

В текущем проекте не слишком много таблиц (около 10–20), но некоторые из них содержат миллионы записей, принадлежащих нескольким сотням конструкций. До сих пор производительность системы была хорошей, но она начинает ухудшаться, поскольку мы расширяем границы дизайна.

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

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

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

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

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

Answer 1

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

Добавление шпинделей (больше дисков) и выполнение нескольких часов работы администратора баз данных часто дешевле, чем модификация / адаптация программного обеспечения.

В противном случае, я бы согласился с @heikogerlach и с подобными постами:

Как сделать версию базы данных MS SQL

Механизмы отслеживания изменений схемы БД

Как вы управляете базами данных при разработке, тестировании и производстве?

Answer 2

Я знаю, что это сумасшедший ответ, но здесь он идет ...

В настоящее время у меня есть похожий сценарий, в котором мне нужно сохранить контроль над версиями базы данных в нескольких местах для системы, использующей MS SQL Server.

То, что я сейчас делаю, - это использование Ruby on Rails Migrations ActiveRecord для контроля версий баз данных. Да, я знаю, что мы говорим о системах Windows, но это прекрасно работает для меня. (Кстати, моя система запрограммирована на VB и .NET)

Я установил Rails на каждом сервере, когда мне нужно обновить схему базы данных, я копирую файлы миграции на сервер и запускаю rake db: migrate, которая обновляет базу данных до последней версии или выполняет откат до нужной версии.

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

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

Я стал лучшим программистом .Net с тех пор, как начал изучать Ruby on Rails. Я задал здесь вопрос перед этим .

Answer 3

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

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

Как сказал Кенг, если вам нужно разбить большие таблицы - рассмотрите возможность их разбиения. И добавить несколько дисков:)

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

Answer 4

У меня здесь похожая ситуация, хотя я использую MySQL. Каждая база данных имеет таблицу версий, которая содержит версию (просто целое число) и краткий комментарий о том, что изменилось в этой версии. Я использую скрипт для обновления баз. Каждое изменение базы данных может быть в одной функции, или иногда одно изменение выполняется несколькими функциями. Функции содержат номер версии в имени функции. Сценарий ищет самый большой номер версии в базе данных и применяет только те функции, которые имеют более высокий номер версии по порядку.

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

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

def change103(...):
    "Create new table."
def change104(...):
    """Transfer data from old table to new table and make
       complicated changes in the process.
    """
def change105(...):
    "Drop old table"
def change106(...):
    "Rename new table to old table"

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

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