我们有两种产品：
产品“社交网络”是一种网络应用程序，它允许公司中的用户进行协作——尤其是在产品“BI 报告”方面。
我们有两个产品共享的一个数据库。他们每个人在数据库中都有自己的表，并且还共享一些“用户管理”表。
每个产品都有自己的发布周期——当我们发布新版本的“社交网络”时，我们不会总是发布新版本的“BI 报告”。
当客户拥有“BI 报告”的“X”版本和“社交网络”的“Y”版本时，我现在对数据库升级/版本控制感到头疼。在内部，数据库有两个版本。
我认为最好的办法是将数据库一分为二——每个产品都有自己的数据库，而“社交网络”则通过“BI 报告”提供的 Web 服务获取用户管理信息。然而，我团队的其他成员认为这工作量太大，不喜欢这个想法。
有没有人有关于在多个应用程序之间共享数据库的经验？
我们的产品由几个不同的模块组成。客户可以选择安装哪些模块。
所有模块共享一个处理用户登录和其他非常常见的站点范围功能的核心部分。
更复杂的是，一些模块依赖于其他模块。我们采用了模块化方法，以便轻松获取大量代码并轻松构建新模块。
综上所述，我们遇到了类似的情况，每个模块都有版本控制，并且可能单独发布。为了解决这个问题，我们做了两件事。
首先，每个模块都使用其当前修订号注册在一个公共数据库表中。它还将任何安全角色和操作注册到公用表中。这些检查足够通用，核心可以处理它。其次，每个模块在数据库中都有自己的模式。即：module1.Table1，module2.Table2。这允许我们在多个模块中拥有相同的表名。
当我们升级给定模块时，它只会影响它自己的 DDL（结构/数据/s'procs/views）。如果模块之间存在依赖关系，则由升级工具处理。它检查数据库以查看是否安装了相关模块的 xyz 版本（或更高版本）。如果是，则允许升级继续。如果不是，则升级中止并告诉用户他们需要先升级其他部分。
摆脱这一点的主要事情是依赖性检查。如果您的模块是真正独立的并且只共享常见的安全检查，那么这并不重要。但是，如果还有其他一些重叠，则每个安装程序都需要检查版本以确保它们兼容。
您甚至可以提供一个“完整的”安装程序，将两个应用程序升级到当前级别，以供那些不同步的应用程序使用。
如果这是一个管理决策，那么我会这样处理：
管理系统需要多少时间/资源？
将系统重新设计成提议的新系统需要多少时间/资源？
进行更改时需要多少时间/资源来管理系统？
假设通过进行更改可以节省一些资源，那么当有投资回报时应该有一个切换期。经理将能够决定从现在到那时的时间长度是否值得当前付出的努力，而不是其他可能需要优先考虑的项目。
hth
如果您更改共享表，则必须更新这两个应用程序。你不能有一个单独的发布周期。
这很明显......不是吗？
我认为这涉及的不仅仅是发布周期——我们自己也在考虑这个问题。
我们的编目应用程序也有 BI 方面，但我们发现 BI 部分可能会影响目录的性能。
我提到这一点是因为您可能会发现两个应用程序的单独数据库不仅可以用于发布管理，还可以用于性能。从您的社交网络应用程序到您的 BI 应用程序的关键数据的定期“归档”可能会为您提供两全其美的优势 - 社交应用程序和发布管理方面的性能。
不确定您的共享用户管理方面......