SQL-Server DB design time scenario (distributed or centralized)

Question

We've an SQL Server DB design time scenario .. we've to store data about different Organizations in our database (i.e. like Customer, Vendor, Distributor, ...). All the diff organizations share the same type of information (almost) .. like Address details, etc... And they will be referred in other tables (i.e. linked via OrgId and we have to lookup OrgName at many diff places)

I see two options:

1. We create a table for each organization like OrgCustomer, OrgDistributor, OrgVendor, etc... all the tables will have similar structure and some tables will have extra special fields like the customer has a field HomeAddress (which the other Org tables don't have) .. and vice-versa.

2. We create a common OrgMaster table and store ALL the diff Orgs at a single place. The table will have a OrgType field to distinguish among the diff types of Orgs. And the special fields will be appended to the OrgMaster table (only relevant Org records will have values in such fields, in other cases it'll be NULL)

Some Pros & Cons of #1:

PROS:

• It helps distribute the load while accessing diff type of Org data so I believe this improves performance.
• Provides a full scope for accustomizing any particular Org table without effecting the other existing Org types.
• Not sure if diff indexes on diff/distributed tables work better then a single big table.

CONS:

• Replication of design. If I have to increase the size of the ZipCode field - I've to do it in ALL the tables.
• Replication in manipulation implementation (i.e. we've used stored procedures for CRUD operations so the replication goes n-fold .. 3-4 Inert SP, 2-3 SELECT SPs, etc...)
• Everything grows n-fold right from DB constraints\indexing to SP to the Business objects in the application code.
• Change(common) in one place has to be made at all the other places as well.

Some Pros & Cons of #2:

PROS:

• N-fold becomes 1-fold :-)
• Maintenance gets easy because we can try and implement single entry points for all the operations (i.e. a single SP to handle CRUD operations, etc..)
• We've to worry about maintaining a single table. Indexing and other optimizations are limited to a single table.

CONS:

• Does it create a bottleneck? Can it be managed by implementing Views and other optimized data access strategy?
• The other side of centralized implementation is that a single change has to be tested and verified at ALL the places. It isn't abstract.
• The design might seem a little less 'organized\structured' esp. due to those few Orgs for which we need to add 'special' fields (which are irrelevant to the other tables)

I also got in mind an Option#3 - keep the Org tables separate but create a common OrgAddress table to store the common fields. But this gets me in the middle of #1 & #2 and it is creating even more confusion!

To be honest, I'm an experienced programmer but not an equally experienced DBA because that's not my main-stream job so please help me derive the correct tradeoff between parameters like the design-complexity and performance.

Thanks in advance. Feel free to ask for any technical queries & suggestions are welcome.

Hemant

Answer 1

I would say that your 2nd option is close, just few points:

Customer, Distributor, Vendor are TYPES of organizations, so I would suggest:

1. Table [Organization] which has all columns common to all organizations and a primary key for the row.

2. Separate tables [Vendor], [Customer], [Distributor] with specific columns for each one and FK to the [Organization] row PK.

The sounds like a "supertype/subtype relationship".

Answer 2

I have worked on various applications that have implemented all of your options. To be honest, you probably need to take account of the way that your users work with the data, how many records you are expecting, commonality (same organisation having multiple functions), and what level of updating of the records you are expecting.

Option 1 worked well in an app where there was very little commonality. I have used what is effectively your option 3 in an app where there was more commonality, and didn't like it very much (there is more work involved in getting the data from different layers all of the time). A rewrite of this app is implementing your option 2 because of this.

HTH