5

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 lead 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

Ross Bush
  • 14,648
  • 2
  • 32
  • 55

4 Answers4

1

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

Mark Broadbent
  • 381
  • 2
  • 4
0

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.

smcdrc
  • 1,671
  • 2
  • 21
  • 29
  • Hi, thanks for the reply!! When you say bring in, do you mean creating a smaller subset persistent copy of the master database data into each subordinate database or a virtual link maintained through the sp’s and views. The reason I am asking is because the more I think about it the more it seems reasonable to create a "table or keys" for each master database table used in the subordinates for ref. integrity. – Ross Bush Feb 10 '11 at 15:26
  • What I did was leave the master data in the Master Database and just refer to where necessary. I can't remember if you can do referenetial integrity across databases, but I was using them as foriegn keys. – smcdrc Feb 10 '11 at 16:31
0

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.

Jon Heller
  • 34,999
  • 6
  • 74
  • 132
0

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.

Jody
  • 8,021
  • 4
  • 26
  • 29