Solved

Design a database with standarized and non standarized data coming from multiple clients SQL Server2008 R2

Posted on 2011-09-13
3
348 Views
Last Modified: 2012-05-12


Hi,

I have a situation where I am tasked with my team to deveop a database for extranet sites which would represent multiple clients data. Now, important thing is there are two parts of incoming data from clients as follows;

1. Standarized Data: Which is common accross all existing and upcoming clients.
2. Client Specific Data: It varies client to client and contains client specific data columns.

Now, when designing database how to cater these two requirements;

1. Should I create new database for every client's extranet database in SQL Server 2008 R2 ?
2. OR  Should I create only one common database to hold all clients data?

If I create only one database to store all clients data including standarized data and non standarized data then how this would be managed?
e.g.,

tbl_StandarizedAndNonStandarizedData

ID,Name,Description,Code,City,client1customfield1,client1customfield2,client2customfield1,client3customfield1,client3customfield2,client3customfield3, ............ so on......

Can you please help me identify pros and cons of both type of implementations of database (means one database or new database for every new client)

Please let me know if you require further information.

Your comments and suggestions are greatly appreciated to solve this design issue.


Thanks.


0
Comment
Question by:ezkhan
3 Comments
 
LVL 33

Expert Comment

by:ste5an
ID: 36535509
Store data always normalized, even it is not standardized, what ever your standards are.

ID,Name,Description,Code,City,client1customfield1,client1customfield2,client2customfield1,client3customfield1

Open in new window


This is an absolute no go.

Storing the data per client makes in many cases sense as it allows you easily to inspect it or track down data issues per client. But this must not be an extra database per client, it can be a single staging table per client or even a folder where you store the raw data. Depending on the number of clients and the amount of data you can also consider using one extra database where you store the clients data before you import it into your main system, e.g. separated by schema.

0
 
LVL 22

Accepted Solution

by:
8080_Diver earned 500 total points
ID: 36536426
The "correct" answer to this can actually be either of the 2 choices that you outlined, obviously, so it is going to depend on how you want to approach it.  That being said, let me see if I can outline some considerations for each alternative:

Unified Database:
In this option, you would have all common data in single tables, e.g. if every client has a ClientInformation record you would have a ClientInformation table that could cantain all of the common columns for the ClientInformation records.
If, for instance, your Clients have some Product record data in common but some (or every) Clients have unique Product data then you would need to have separate tables, one for each Client with their unique columns and a Foreign Key (containing the Primary Key from the CommonProduct table) linking the data back to the CommonProducts table.
It should be noted that this approach will significantly complicate your application's code.

Separate Databases:
Essentially, this simplifies the application by having separate sets of tables that conform exactly to the requirements of the each CLient.
However, this also complicates the application because, while it may not have to "know" when to include an auxiliary table because a Client has some unique aspects to a given table, it does have to "know" which client it will be working with.

Observaton/Suggestion:
Having been a developer in the past, I can sympathize with those who will be having to develop the application so that it handles the needs of all clients, including those with unique data.  However, if you opt for the unified database approach, this can be mitigated, to some degree, by assigning each Client a Schema (which may include the dbo Schema for the Clients that have a "plain vanilla" set up).  Once that is done, you could provide Stored Procedures within each Schema and use them to access the data.  You would only have to Schema specific Stored Procedures for accessing tables that may have Client specific auxiliary tables.  Using my previous example table names, you would have a dbo.usp_Fetch_Client_Information Stored Procedure for accessing the ClientInformation table; however, you would have both a dbo.usp_Fetch_Products and a Client1.usp_Fetch_Products Stored Procedure for accessing the CommonProducts and, where appropriate, Client1.AuxProducts tables (as a resultset from a query joining the two tables).  This would reduce your efforts, within the database, to creating the unique auxiliary tables within the Schemas and the corresponding unique Storoed Procedures.
0
 

Author Closing Comment

by:ezkhan
ID: 36556601
Thanks alot. This helps
0

Featured Post

Comprehensive Backup Solutions for Microsoft

Acronis protects the complete Microsoft technology stack: Windows Server, Windows PC, laptop and Surface data; Microsoft business applications; Microsoft Hyper-V; Azure VMs; Microsoft Windows Server 2016; Microsoft Exchange 2016 and SQL Server 2016.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article explains how to reset the password of the sa account on a Microsoft SQL Server.  The steps in this article work in SQL 2005, 2008, 2008 R2, 2012, 2014 and 2016.
Ever needed a SQL 2008 Database replicated/mirrored/log shipped on another server but you can't take the downtime inflicted by initial snapshot or disconnect while T-logs are restored or mirror applied? You can use SQL Server Initialize from Backup…
Video by: Steve
Using examples as well as descriptions, step through each of the common simple join types, explaining differences in syntax, differences in expected outputs and showing how the queries run along with the actual outputs based upon a simple set of dem…
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…

911 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

20 Experts available now in Live!

Get 1:1 Help Now