I'm working on a series of inter-related but separate web applications, all situated on the same host:
Super Admin
|
---Site Network Admin
| |
| ---Site
| |
| ---Site
| |
| ---Site
|
---Site Network Admin
|
---Site
|
---Site
|
---Site
All three will have access to the same core library (Zend Framework), and separate application libraries for each tier in the network - thus 3 applications and one library - but different configurations to support unique instances.
I'm interested to hear people's opinion on the best database strategy to support these applications.
On the one hand, I could deploy one database, or perhaps one for each application level (i.e. 3). This has the advantage of being easy to roll out changes, but the disadvantage that users share the access burden - i.e. if one user is really hammering the database, the performance of other applications sharing the database will suffer. Another disadvantage is that any data corruption could potentially affect all end users.
On the other, I could utilise a series of databases - one for the first two tiers to share administrative data - but separate instances for each site deployed on the network. This has the advantage that end users are isolated and thus data corruption is more easy to contain. The disadvantage is obviously the converse of the previous example - in that changes are then harder to roll out across the network.
My thinking is that it's dictated by usage vs user population. If you have low quantities of users, but they interact with the database a lot - then plan B is best. If it's the former, that you have high yields of users with low interaction rates - then plan A is best.
I'm interested to hear other people's thoughts as to the best approach for dealing with this situation.