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