Hypothetical:



You are designing a product from the ground up. In the end you will have data for 20 different companies in said product. Do you have one database and add a customer ID to each table, or do you have 20 different databases?



I can see arguements for each scenario....



Opinions?




Keith Chisarik

In our medical software we have the ability to support multiple instances which is ultimately a different database for each.  Starting with 1.6, the DDT had the ability to take a single profile and allow you to deploy to a different database name using the same profile package.  This is how we support multiple "comapnies" on the same server.  If you have the need to allow reports, etc. to have all of the information included for all companies, then you may want to use the same database...which we too have this need for some things and in these cases we have a company PK field in every table which is a separation....but this complicates every query you write because you ALWAYS have to take this into account.

In my opinion, the multiple databases is the cleanest and easiest to maintain.  But as some of the other guys have mentioned as well, it really depends on your needs.

One thing to keep in mind is that it is always easier to merge databases versus break them apart.  So I think the least number of risks are with the multiple databases.