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 di

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