具有不同发布周期的两个应用程序是否应该共享一个数据库
我们有两种产品：
- BI 报告（商业信息）
- 社交网络
产品 “社交网络”是一个 Web 应用程序，它允许公司中的用户进行协作 - 特别是在产品“BI 报告”方面。
我们拥有两个产品共享的一个数据库。他们每个人在数据库中都有自己的表，并且还共享一些“用户管理”表。
每个产品都有自己的发布周期——当我们发布新版本的“社交网络”时，我们不会总是发布新版本的“BI 报告”。
当客户拥有“BI 报告”版本“X”和“社交网络”版本“Y”时，我现在对数据库升级/版本控制感到头疼。数据库内部有两个版本。
我认为最好的想法是将数据库一分为二 - 每个产品都有自己的数据库，“社交网络”通过“BI 报告”提供的 Web 服务获取用户管理信息。然而，我团队的其他成员认为这工作量太大，并且不喜欢这个想法。
有人有在多个应用程序之间共享数据库的经验吗？
We have two products:
- BI reports (Business Information)
- Social networking
Product 'Social networking' is a web application, which allow users in a company to collaborate - in particular with regards to product 'BI reports'.
We have one database which both products share. They each have their own tables in the database, and also share some 'User management' tables.
Each product has it's own release cycle - when we release a new version of 'Social networking', we will not always release a new version of 'BI reports'.
I now have headaches regarding database upgrading/versioning, when a customer has version 'X' of 'BI reporting' and version 'Y' of 'Social networking'. Internally the database then has two versions.
I think the best idea is to split the database in two - each product get's it's own database and 'Social Networking' gets User Management information through a Web service offered by 'BI reports'. However the rest of my team think this is too much work and don't like the idea.
Has anyone any experience with regards to sharing databases between multiple applications?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我们有一个由几个不同模块组成的产品。客户可以挑选安装哪些模块。
所有模块共享一个核心部分，用于处理用户登录和其他非常常见的站点范围功能。
使问题变得复杂的是，某些模块依赖于其他模块。我们采用模块化方法，以便轻松获取大量代码并轻松构建新模块。
综上所述，我们有类似的情况，每个模块都有版本控制并且可能单独发布。为了解决这个问题，我们做了两件事。
首先，每个模块都使用其当前修订号注册在公共数据库表中。它还会将所有安全角色和操作注册到公用表中。这些检查足够通用，核心可以处理它。其次，每个模块在数据库内都有自己的模式。即：模块1.Table1，模块2.Table2。这允许我们在多个模块中拥有相同的表名。
当我们升级给定模块时，它只会影响它自己的DDL（结构/数据/s'procs/views）。如果模块之间存在依赖关系，则由升级工具处理。它检查数据库以查看是否安装了相关模块的 xyz 版本（或更好版本）。如果是，则允许继续升级。如果没有，则升级将中止并告诉用户他们需要先升级其他部分。
最重要的是依赖项检查。如果您的模块确实是独立的并且仅共享通用的安全检查，那么这并不重要。但是，如果存在其他重叠，则每个版本的安装程序都需要检查版本以确保它们兼容。
您甚至可以提供一个“完整”安装程序，将两个应用程序升级到当前级别，以应对那些不同步的应用程序。
We have a product that is made up of several different modules. Customers can pick and choose which modules are installed.
All of the modules share a core piece which handles user logins and other very common site wide features.
Complicating this is that some of the modules are dependent on others. We took a modular approach in order to easily take large chunks of code and easily build new modules.
All of that said, we have a similar situation in that each module is versioned and potentially released separately. To handle this we did two things.
First, each module is registered in a common db table with it's current revision number. It will also register any security roles and actions into the common tables. These checks are generic enough that the core can handle it. Second, each module has it's own schema inside the database. ie: module1.Table1, module2.Table2. This allows us to have the same table names across multiple modules.
When we upgrade a given module, it only impacts it's own DDL (structure/data/s'procs/views). If there is a dependency between modules, this is handled by the upgrading tool. It checks the database to see if version xyz (or better) of the related module is installed. If it is then the upgrade is allowed to continue. If not, then the upgrade aborts and tells the user they need to upgrade the other parts first.
The main thing to take away from this is the dependency check. If your modules are truly separate and only share the common security checks then it doesn't matter all that much. However, if there is some other overlap then the installer for each needs to check the versions to make sure they are compatible.
You might even provide a "complete" installer which upgrades both apps to the current level for those that are way out of sync.
如果这是一个管理决策，那么我会这样处理：
按原样管理系统需要多少时间/资源？
将系统重新改造为提议的新系统需要多少时间/资源？
进行更改时管理系统需要多少时间/资源？
假设通过进行更改可以节省一些资源，那么在获得投资回报时应该有一个转换期。经理将能够决定从现在到那时之间的时间长度是否值得当前付出的努力与可能需要优先考虑的其他项目相比。
哈
if this is a management decision, then I would approach it like this:
how much time/resources does it take to manage the system as is?
how much time/resources will it take to rework the system into the proposed new system?
how much time/resources will it take to manage the system when the changes are made?
Assuming there is some resource savings by making the changes, then there should be a cutover period when there is a return on the investment. a manager would be able to decide if the length of time between now and then is worth the current expense of the effort vs other items that may need to take priority.
hth
我认为这不仅仅涉及发布周期——我们自己也对此进行了很多思考。
我们的编目应用程序也有 BI 方面的内容，但我们发现 BI 部分可能会影响目录的性能。
我提到这一点是因为您可能会发现两个应用程序的单独数据库不仅可以用于发布管理，还可以提高性能。从社交网络应用程序到 BI 应用程序的关键数据的定期“归档”可能会给您带来两全其美的效果 - 社交应用程序的性能和发布管理。
不确定您的共享用户管理方面...
I think this touches on more than release cycle - we're thinking about this quite a bit ourselves.
Our cataloging application has a BI aspect to it as well, but we're finding that the BI part might be affecting the performance of the catalog.
I mention this becuase you might find that seperate databases for the two applications might work out not only for release management but also performance. Periodic 'archives' of key data from your social-netowrking app to your BI app might give you the best of both worlds - performance in the Social app and release management.
Not sure about the shared user management aspect for you...
如果您更改共享表，则必须更新这两个应用程序。您不能有单独的发布周期。
这很明显……不是吗？
If you change a shared table you must update both apps. You can't have a separate release cycle.
This is obvious.... no?