一个用户数据库服务于多个应用程序数据库

Question

我正在管理一个相当庞大的数据库，这个数据库的复杂性和设计已经从单一的应用程序数据库中增加。现在有计划添加第五个应用程序，并携带它自己的模式和特定数据。我一直在研究SSO解决方案，但那不是我真正想要的。我的目标是拥有一个客户注册点，登录和授权点。

理想情况下，每个应用程序都会请求身份验证，并授予多个应用程序的授权，然后应用程序将连接到适当的数据库进行操作。我没有亲身体验这种分离程度的经验，因为一个数据库多年来一直在毫无问题地搅动着。任何最佳实践的论文，将不胜感激:)

我会设想，维持共享数据和核心数据库 - 客户/公司/产品

1. 核心表和主键 - 要保持参照完整性应我在每个“应用程序”数据库中有一个较小的复制表。有哪些方法可以在各种数据库之间共享密钥并确保参照完整性？

2. 复制 - 两个订户当前正从生产数据库中提取数据，其中数据随后分批生成DW解决方案进行报告。我是否会走上一条可能导致挫败感的道路？

3. 数据完整性 - 我怎样才能确保例子： DATABASE_X.PREFERENCES.USER_ID =总是引用= CORE_DATABASE.USERS.USER_ID

4. 报告 - 我愿意渡过什么类型的障碍将多个数据库中的数据复制/转换成一个报告数据库？

5. 白皮书 - 任何人都可以在实践中找到对此策略的很好的参考？

感谢

Answer 1

几个网址给你。横向扩展实现可以变化很大以适应需求，但希望这些可以帮助您。

http://blogs.msdn.com/b/sqlcat/archive/2008/06/12/sql-server-scale-out.aspx

这一个是2005年中心却是非常好的 http://msdn.microsoft.com/en-us/library/aa479364.aspx#scaloutsql_topic4

这一个很好的解决方案报告... http://msdn.microsoft.com/en-us/library/ms345584.aspx

给你分析服务一个太:) http://sqlcat.com/whitepapers/archive/2010/06/08/scale-out-querying-for-analysis-services-with-read-only-databases.aspx

Answer 2

我创造了这样的事情在几年前使用视图和存储过程中的数据，使从主数据库到下级数据库。这将允许您很容易地将这些主表连接到其他从属表中。

Answer 3

你看过使用RAC吗？您可以有多个物理数据库，但只有一个逻辑数据库。这将解决您的所有完整性问题。并且您可以为报告预留节点。

Answer 4

不要扔掉有单独的应用程序和Web服务通过（式的）请求连接的登录/关功能的想法。我已经看到以这种方式分开的账单/用户注册系统。虽然规模非常大，但这可能不是一个好主意。