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

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

hth

Answer 3

Я думаю, что это затрагивает больше, чем цикл выпуска - мы думаем об этом сами.

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

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

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

Answer 4

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

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