Должны ли два приложения с отдельными циклами выпуска совместно использовать одну базу данных

У нас есть два продукта:

  1. Отчеты BI (бизнес-информация)
  2. Социальная сеть

Продукт «Социальные сети» — это веб-приложение, которое позволяет пользователям в компании сотрудничать, в частности, в отношении продукта «Отчеты BI».

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

У каждого продукта есть свой цикл выпуска — когда мы выпускаем новую версию «Социальных сетей», мы не всегда выпускаем новую версию «Отчетов BI».

Теперь у меня возникают головные боли, связанные с обновлением/версионированием базы данных, когда у клиента есть версия «X» «отчетности BI» и версия «Y» «социальной сети». Внутри база данных имеет две версии.

Я думаю, что лучшая идея состоит в том, чтобы разделить базу данных на две части: каждый продукт получает свою собственную базу данных, а «Социальная сеть» получает информацию об управлении пользователями через веб-службу, предлагаемую «отчетами BI». Однако остальная часть моей команды считает, что это слишком много работы, и им не нравится эта идея.

Есть ли у кого-нибудь опыт в отношении совместного использования баз данных между несколькими приложениями?


database architecture database-design database-migration
person GarethOwen    schedule 08.12.2010    source источник

Ответы (4)


arrow_upward
3
arrow_downward

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

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

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

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

Во-первых, каждый модуль регистрируется в общей таблице базы данных с текущим номером версии. Он также зарегистрирует любые роли безопасности и действия в общих таблицах. Эти проверки достаточно общие, чтобы ядро ​​могло с ними справиться. Во-вторых, каждый модуль имеет собственную схему внутри базы данных. то есть: модуль1.Таблица1, модуль2.Таблица2. Это позволяет нам иметь одинаковые имена таблиц в нескольких модулях.

Когда мы обновляем данный модуль, это влияет только на его собственный DDL (структура/данные/процессы/представления). Если между модулями есть зависимость, это обрабатывается средством обновления. Он проверяет базу данных, чтобы узнать, установлена ​​ли версия xyz (или лучше) соответствующего модуля. Если это так, то обновление может быть продолжено. Если нет, то обновление прерывается и пользователю сообщается, что сначала нужно обновить другие части.

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

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

person NotMe    schedule 08.12.2010
comment
поэтому вы используете отдельные схемы в базе данных, каждая из которых обновляется независимо. Что вы будете делать, если изменится общее «ядро» — все ли модули нуждаются в обновлении? Или есть элемент обратной совместимости? - person GarethOwen; 08.12.2010
comment
@GarethOwen: ядро ​​обрабатывается немного иначе, чем другие. Во-первых, он редко менялся. Я могу вспомнить 2 обновления за последние 3 года. Ни одна из ситуаций не включала обесценивание чего-либо. Я думаю, что мы потратили 4 месяца только на его дизайн, чтобы убедиться, что он охватывает то, что нам нужно, и только то, что нам нужно. - person NotMe; 08.12.2010
comment
Вы можете применять принципы ООП к схемам; такие принципы, как принцип стабильных зависимостей, имеют дело с изменениями и способами их изоляции. Очевидно, вы хотите спроектировать любой общий компонент/схему так, чтобы он выполнял только одну работу и делал ее хорошо — с целью свести к минимуму ситуации, которые могут подвергнуть его изменению. - person Adrian K; 10.12.2010

arrow_upward
2
arrow_downward

если это управленческое решение, то я бы подошел к нему так:

  1. сколько времени/ресурсов требуется для управления системой как есть?

  2. сколько времени/ресурсов потребуется для преобразования системы в предлагаемую новую систему?

  3. сколько времени/ресурсов потребуется для управления системой после внесения изменений?

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

чт

person Randy    schedule 08.12.2010
comment
это не решение руководства. Это коллективное решение относительно того, как выполнить миграцию данных, когда версия базы данных не соответствует 1 к 1 версии (версиям) продукта. - person GarethOwen; 08.12.2010
comment
хорошо, но даже внутри команды есть решение о том, как использовать свои ресурсы. - Вы определили количество своих «головных болей»? - person Randy; 08.12.2010
comment
+1 за попытку количественно определить головную боль. Не все проблемы стоит решать :) - person Ronnis; 09.12.2010

arrow_upward
1
arrow_downward

Я думаю, что это касается не только цикла выпуска — мы сами об этом много думаем.

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

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

Не уверен насчет общего аспекта управления пользователями для вас...

person n8wrl    schedule 08.12.2010
comment
производительность - хороший момент - я думаю, что, имея одну базу данных для каждого продукта, у меня больше гибкости для оптимизации, если это необходимо. - person GarethOwen; 08.12.2010
comment
Разве схема не является важной частью здесь? Поскольку ваши решения должны быть привязаны только к их конкретной схеме, это позволит вам использовать две схемы в одной или разных базах данных. - person Adrian K; 09.12.2010
comment
@Adrian K - можно ли заставить схему не иметь доступа к другой схеме в той же базе данных? (я не специалист по базам данных) - person GarethOwen; 09.12.2010
comment
Неправильный вопрос: пользователи обращаются к объектам в базе данных (например, к таблицам, которые являются частью данной схемы). Таким образом, используя контроль доступа, вы можете ограничить доступ к схеме на основе пользователей/ролей. Схема — это просто группа объектов в базе данных (чаще всего таблицы). - person Adrian K; 10.12.2010

arrow_upward
1
arrow_downward

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

Это очевидно... нет?

person mike    schedule 08.12.2010
comment
Это может показаться очевидным, но я не уверен. Рассмотрим сценарий Криса Ливерли: есть два модуля (A и B), оба из которых используют таблицы в ядре. Если новый релиз модуля А требовал изменения ядра, но модуль Б будет работать с новым ядром без обновления, то мне не нужен новый релиз модуля Б. Но я думаю, что для этого нужна некоторая ручная работа, чтобы определить, какой модули остаются совместимыми при изменении ядра. - person GarethOwen; 09.12.2010
comment
Да... но все же, если элемент базы данных изменен, что требует изменений в обоих приложениях... вы должны изменить оба приложения. (очевидное) У вас есть 3 варианта. 1: повезет с совместимыми изменениями. 2: иметь общий цикл выпуска. 3: отдельные базы данных. - person mike; 09.12.2010