We recently released as Basecamp-esque application where each client system operated under a unique subdomain i.e. http://ibm.example.com.au. Each client system was an individual database, however there was only a single code base.
Recent discussions, regarding soon to be developed application, have us leaning toward a single database for all client system. Client’s will be linked to their respective data via some sort of identifier column i.e. client_id.
The topic is of some importance because the project is in very early days, and this decision will drive the application’s direction.
I’m curious as to the (dis)advantages of each approach.
note: the application will be developed with
Symfony 1.4.x (due to the pushed back release date)
I would say go with a single database, presumably you don’t yet have the issue of scalability, and even having a single database you still have many options should database load become an issue.
The upside is easier management for things like backup, schema changes, connections, simplicity.
Don’t know of any case studies, but it becomes much harder to scale out, be fault tolerant for some clients, etc. if they are combined. Definitely lowers admin if you work on one db v 100.
What about running a hybrid solution where you use one central database, then a seperate database for each client.
The centralised database would be an rdbms that manages the tenants, eg stores the details of who the clients are and what options they have. The each client would then have a much simpler document based database such as mongodb which stores their specific data.
^^^This man speaks the truth. In any case, I would build it so that each client had their own data separated mainly because that makes securing things a bit easier – can’t access data it doesnt know exists, rite?