Timeline for 500 databases or 1 database with 500 tables or just 1 table with all the records?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 30, 2014 at 6:24 | vote | accept | Phil Wright | ||
| Oct 24, 2014 at 15:50 | comment | added | Nemanja Boric | I have a hands-on experience of 1-per-customer databases and I can confirm everything that Maru noted here. Backups, cross-db queries and, most important, keeping structure synced after changes are real pain - it happens at least three times per year that we forget about one customer. Scripts make maintenance easier, but the problem still occurs from time to time. Plus side is isolation, so you can do A-B-C testing and deploying simple as cake. | |
| Oct 24, 2014 at 11:42 | comment | added | IdeaHat | This method also doesn't preclude 1. There may be instances where one day you DO want to split the database for a subset of customers (like, they want to pay you millions of dollars to have their own enterprise server). However, that group may have many different sub-customers that want to be listed differently. In this case, deploying them a single database with a single table will be a breeze comparably. Also, doing queries across organizations becomes much less of a nightmare with this method. | |
| Oct 24, 2014 at 8:55 | comment | added | Daniel Hollinrake | Following on from Maru's comments, don't be scared by having a million rows in a database table. With a good index based on the customer name you should get good performance. | |
| Oct 24, 2014 at 3:55 | history | answered | Maru | CC BY-SA 3.0 |