问题
It more architectural question. What is best practice creating multi-tenancy applicaton? Use single database for all tenants or use separate schema/database instance for each tenant?
回答1:
The real issue here is overall customer (or rather activation) service segregation, which can be thought of at different levels of resource sharing for the DB tier:
- Application logic level: doesn't require separate schema/database, can have better performance, can lead to better resources optimization, can help implementing cross-activation logic (if any) but offers least segregation: one activation can impact (because of wrong behaviour combined with insufficient restrictions or simply because of bugs) all of data, performance and availability service levels of other activations.
- Schema level: as above but it is almost impossible for activations to impact data service levels of other activations and much more difficult for application logic issues to do so.
- Database level: as above but stronger; from this point down backing up data starts becoming more involved.
- Database service process level: as above but it's almost impossible even for applications to impact cross-activations data service levels. Furthermore, more performance tuning for performance segregation becomes possible at OS-level but the computational and I/O resources are still shared, so no availability segregation is possible either.
- Database virtual instance (= virtual server) level: as above but it is unlikely to have cross-activations performance and availability issues, still not impossible though when virtual servers are on the same physical hardware.
- Database physical instance (= physical server) level: as above but practically impossible to have cross-activations performance and availability issues.
The above reasoning is only about the DB tier, which is normally the downmost one, but similar reasoning can be applied to any other tier as well.
That is, in order to have real full-blown customer service level segregation in all concerns (I/O, network, computation, availability ecc.) you have to give up multi-tenancy and any form of resource sharing altogether. At its extreme, this reasoning means you'd need a separate physical IDC with dedicated connectivity per activation.
回答2:
A little bit more info to the story. The company requested my input on multi-tenancy is start-up using shared hosting - so the number of DB instances they can use is limited.
Here is my proposition to the requester: Go with Single DB solution as this does not require an additional cost
To fulfill requirement for tenant data segregation I recommend using Views instead of Tables solution. Views instead of Tables: 1. Currently user selects data from a table directly 2. In future state a table in DB will be hidden in a view. The view will use currently logged in DB User as selection criteria. This way virtual tenant data segregation is accomplished.
来源：https://stackoverflow.com/questions/25670545/multi-tenancy-application-one-database-or-multiple-copies-of-same-database