One User database servicing multiple application databases

I am administering a rather large database that has grown in complexity and design from a single application database. Now there is a plan to add a fifth application that carries with it its own schema and specific data. I have been researching SSO solutions but that is not really what I am after. My goal is to have one point of customer registration, logins and authorization.

Ideally, each application would request authentication and be given authorization to multiple applications, where the applications would then connect to the appropriate database for operations. I do not have first hand experience dealing with this degree of separation as the one database has been churning flawlessly for years. Any best practice papers would be appreciated :)

I would envision a core database that maintained shared data - Customer/Company/Products

1. Core tables and primary Keys –To maintain referential integrity should I have a smaller replicated table in each “application” database. What are some ways to share keys among various databases and ensure referential integrity?

2. Replication – Two subscribers currently pull data from the production database where data is later batched into a DW solution for reporting. Am I going down a road that can l开发者_开发知识库ead to frustration?

3. Data integrity – How can I ensure for example that: DATABASE_X.PREFERENCES.USER_ID =always references a= CORE_DATABASE.USERS.USER_ID

4. Reporting – What type of hurdles would I cross to replicate/transform data from multiple databases into one reporting database?

5. White Papers - Can anyone find good refernces to this strategy in practice?

Thanks

A few urls for you. Scale out implementations can vary wildly to suit requirements but hopefully these can help you.

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

this one is 2005 centric but is VERY good http://msdn.microsoft.com/en-us/library/aa479364.aspx#scaloutsql_topic4

this one a good solution for reporting... http://msdn.microsoft.com/en-us/library/ms345584.aspx

given you an analysis services one too :) http://sqlcat.com/whitepapers/archive/2010/06/08/scale-out-querying-for-analysis-services-with-read-only-databases.aspx

I created something like this a few years ago using views and stored procedures to bring in the data from the Master database into the subordinate databases. This would allow you to fairly easily join those master tables into the other subordinate tables.

Have you looked into using RAC? You can have multiple physical databases but only one logical database. This would solve all of your integrity issues. And you can set aside nodes just for reporting.

Don't throw out the idea of having separate applications and linking the logon/off functions via webservice (esque) requests. I have seen billing/user registration systems separated in this way. Though at extremely large scales, this might not be a good idea.