Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
vipul_parekh_b
Starting Member
4 Posts |
 Posted - 2007-09-06 : 10:36:33
|
| Hi,This is what I am planning to do.Client has to register their company and then, they can use my software made in asp.net.Now here is the real question.Should I create a db for every new client OR I should use one database for all the clients?I am worried about these points.1. If I will use one database for all then the performance can be effected because of data size.2. If I make new database then, maintenance will be a hell.Do you guys have any suggestions on this?Regards,Vipul Parekh |
|
|
Kristen
Test
22859 Posts |
Posted - 2007-09-06 : 10:44:26
|
1. I doubt performance will be an issue, unless you will have many many millions of records2. I agree. Maintenance will be a painI would add a third:3) If you use a single database (with relevant tables having a "ClientCode" in them, say), then there is a risk that, through software bug, a client will see data for another client. Could be very embarrassing ...We have some of each. We make clear in our T&C's (on single-shared-database applications) that clients a) may, due to software error, see data from another client and b) if they do they are required to keep it confidential and c) report it immediately (otherwise their license is revoked). But that is only window dressing and would not help with the damage to PR if it happened  Kristen |
 |
|
|
vipul_parekh_b
Starting Member
4 Posts |
Posted - 2007-09-06 : 10:52:05
|
| Thankx Kristen,This what I like here. You get quick replies.You got my problem exactly.1. Yes, there will be millions of data in some tables.2. Is there any way so that I can fire an update to all the database?3. I have the same fear.Any one else with any suggestios?Also, is it possible to handle this situation in sql 2005?Vipul Parekh |
|
|
|
Kristen
Test
22859 Posts |
Posted - 2007-09-06 : 10:57:36
|
| 2. Well, you can script stuff and then just run the script on all database.We have an e-Commerce application that is used by lots of people. Each has their own database, some have their own servers, etc.For "new versions" we products scripts of all the changes, and then apply the scripts, in order, to get their database from its current version to the "latest version".We do that anyway in order to be able to update our QA, Beta, Staging and Production databases once new stuff is released from DEV ... (and keep everything in a Version Control system so we can see what changed and when).1. Is that time related data - like invoices that have a "reasonable" number of rows in the "current period", but lots of historical data? Because if so you can use horizontal-partitioning (i.e. one table per period) to keep the per-table row count down.Kristen |
|
|
|
|
|
|
|
|
Multiple Database Management