Если два приложения с отдельными циклами выпуска совместно используют одну базу данных - PullRequest
4 голосов
/ 08 декабря 2010

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

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

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

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

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

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

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

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

Ответы [ 4 ]

3 голосов
/ 08 декабря 2010

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

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

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

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

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

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

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

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

2 голосов
/ 08 декабря 2010

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

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

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

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

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

НТН

1 голос
/ 08 декабря 2010

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

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

1 голос
/ 08 декабря 2010

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...