- [Instructor] This design pattern,…single-database tenancy, is probably the easiest…that we're going to talk about to implement,…but ultimately, the most limiting.…It does have one pretty common use case, consumers.…If you're going to build a database for each customer,…if you have 10,000, that's going to be highly problematic.…You're not going to want to do that.…Sharding will give you horizontal scale.…This model will give you a level of simplicity.…However, in both of these models,…since data is going to be mixed amongst customers…in single tables, you need to consider…how to use row-level security and encryption…so that in any sort of reporting,…customers can't see each other's data.…
The other problem with this is management operations…that are focused on individual tenants,…are much more complex to implement…in the multi-tenant databases.…A good example would be a point-in-time restore of data…for just a single tenant.…You would probably have to restore that database back…and retrieve that single set of rows just for that customer.…
Released
11/12/2018- Designing for high-write and high-read workloads
- Designing an archiving model
- Leveraging SQL features such as portioning and compression
- Building a tenancy model
- Using Azure design patterns for scaling
Share this video
Embed this video
Video: Multitenant app with database per tenant