database - 具有不同发布周期的两个应用程序是否应该共享一个数据库

Question

我们有两种产品:

1. BI 报告(商业信息)
2. 社交网络

产品“社交网络”是一种 Web 应用程序，它允许公司中的用户进行协作 - 特别是在产品“BI 报告”方面。

我们有一个两个产品共享的数据库。他们每个人在数据库中都有自己的表，并且还共享一些“用户管理”表。

每个产品都有自己的发布周期 - 当我们发布新版本的“社交网络”时，我们不会总是发布新版本的“BI 报告”。

当客户拥有“BI 报告”的“X”版本和“社交网络”的“Y”版本时，我现在对数据库升级/版本控制感到头疼。在内部，数据库有两个版本。

我认为最好的办法是将数据库一分为二——每个产品都有自己的数据库，“社交网络”通过“BI 报告”提供的 Web 服务获取用户管理信息。然而，我团队的其他成员认为这工作量太大，不喜欢这个想法。

有人在多个应用程序之间共享数据库方面有经验吗？

Answer 1

我们的产品由几个不同的模块组成。客户可以挑选安装哪些模块。

所有模块共享一个核心部分，该部分处理用户登录和其他非常常见的站点级功能。

复杂的是一些模块依赖于其他模块。我们采用模块化方法，以便轻松获取大量代码并轻松构建新模块。

综上所述，我们有一个类似的情况，即每个模块都有版本控制并且可能单独发布。为了解决这个问题，我们做了两件事。

首先，每个模块都在一个通用的数据库表中注册了它的当前修订号。它还会将任何安全角色和操作注册到公用表中。这些检查足够通用，核心可以处理它。其次，每个模块在数据库中都有自己的模式。即:module1.Table1，module2.Table2。这允许我们在多个模块中使用相同的表名。

当我们升级给定的模块时，它只会影响它自己的 DDL(结构/数据/s'procs/ View )。如果模块之间存在依赖关系，则由升级工具处理。它检查数据库以查看是否安装了相关模块的 xyz 版本(或更高版本)。如果是，则允许升级继续。如果没有，则升级中止并告诉用户他们需要先升级其他部分。

要摆脱的主要事情是依赖性检查。如果你的模块是真正独立的并且只共享通用的安全检查，那么它就没有那么重要了。但是，如果存在其他一些重叠，则每个安装程序都需要检查版本以确保它们兼容。

您甚至可以提供一个“完整”的安装程序，将两个应用程序升级到当前级别，以解决那些不同步的应用程序。