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

5
我正在管理一个相当大的数据库,它从单一应用程序数据库发展成了一个复杂的设计。现在有一个计划添加第五个应用程序,它带有自己的架构和特定数据。我一直在研究SSO解决方案,但那不是我想要的。我的目标是拥有一个客户注册、登录和授权的统一点。
理想情况下,每个应用程序都会请求认证,并被授权访问多个应用程序,然后这些应用程序将连接到适当的数据库进行操作。由于这个数据库已经运行多年没有问题,我没有处理这种程度分离的第一手经验。任何最佳实践论文都将不胜感激:)
我会设想一个核心数据库来维护共享数据-客户/公司/产品
1. 核心表和主键 - 为了维护引用完整性,我是否应该在每个 "应用" 数据库中有一个较小的复制表?有哪些方法可以在各种数据库之间共享关键字并确保引用完整性?
2. 复制 - 目前有两个订阅者从生产数据库中提取数据,其中数据稍后被批处理到DW解决方案进行报告。我正在走一条可能会导致挫败的路吗?
3. 数据完整性 - 我如何确保例如:DATABASE_X.PREFERENCES.USER_ID =始终引用 CORE_DATABASE.USERS.USER_ID?
4. 报告 - 从多个数据库复制/转换数据到一个报告数据库会遇到哪些障碍?
5. 白皮书 - 是否有人能找到这种策略的好参考资料?
谢谢
4个回答

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


谢谢,非常棒的文章,正是我所寻找的。 - Ross Bush

0
我几年前用视图和存储过程创建了类似的东西,将主数据库中的数据引入到从属数据库中。这样可以让您相对容易地将那些主表加入到其他从属表中。

嗨,谢谢回复!当您说“bring in”时,您是指将主数据库数据的较小子集持久地复制到每个从属数据库中,还是通过存储过程和视图维护的虚拟链接?我之所以问是因为我越想越觉得为每个在从属数据库中使用的主数据库表创建“表或键”以供参考完全是有道理的。 - Ross Bush
我所做的是将主数据留在主数据库中,只在必要时引用。我不记得是否可以跨数据库进行参照完整性,但我将它们用作外键。 - smcdrc

0
你有考虑过使用 RAC 吗?你可以拥有多个物理数据库,但只有一个逻辑数据库。这可以解决你所有的完整性问题。并且你可以将节点设置为仅用于报告。

0
不要放弃通过Web服务请求将独立应用程序和登录/注销功能链接起来的想法。我曾经看到过将计费/用户注册系统分开的做法。尽管在极大规模下,这可能不是一个好主意。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接