这更像是一个概念性问题，因此如果它们能够实现相同的概念，那么堆栈的变化是受欢迎的。我们目前正在使用MySQL并将一些服务扩展到MongoDB。
我们的想法是，我们希望能够管理单个物理数据库模式/结构，以便调整，扩展等不会变得过于繁琐，因为使用该结构的客户端数量增长到数千，数十个但是，我们希望在这个级别上分离他们的数据，而不是简单地在应用层，以提供更严格的分离。是否可以使用相同的结构为每个客户创建虚拟箱，但是它们的数据在结构上是否彼此分离？
通常的方法显然是直接或通过外部关系向每行数据添加客户端密钥，但考虑到我们无法预测20/20我们系统上的黑客攻击可能会导致“跨客户端”数据检索，我想进一步将分离嵌入到几乎结构层面。
我还在这里阅读了另一篇文章：MySQL: how to do row-level security (like Oracle's Virtual Private Database)?使用“视图”作为方法但是这似乎在客户列表中越大越好。
谢谢！
----编辑----
根据以下建议的一些文献，这里有关于我们意图的更多信息：
@Stennie提供的MSDN文章中概述的最接近的情况将是单个数据库，多模式，但不同的是，我们对创建后自定义客户端模式不感兴趣，我们实际上更喜欢它们仍然锁定在父/主模式上。
理想情况下，解决方案会将每个架构保持链接到父表集结构，而不是简单地复制它，希望对所有客户端/租户架构级别对父架构或主架构进行任何更改。
更进一步，在一个集群中，我们可以拥有一个具有主模式的主服务器，并且每个服务器都可以从中复制，但使用一组分片的租户。然后，可以在不中断的情况下通过集群对主服务器进行更改，并保持所有实例的一致性，从而使我们能够更快地更新应用程序层，因为所有数据库都与更新的模式兼容。
希望有道理，我在这个级别上仍然有点新鲜。
答案 0 :(得分：1)
有一些常见的基础架构方法，从“无共享”（又名multi-instance）到“分享所有内容”（又名multi-tenant）。
例如，对“虚拟容器”的直接方法是使用共享数据库服务器为每个客户端分配数据库。这是在两个共享极端之间的某个地方，因为您的客户将共享数据库服务器基础结构，但保持他们的数据和模式分离。
每个客户端的数据库方法允许您：
一些潜在的缺点包括：
如果您对多租户进行一些研究，您会发现一些其他解决方案，从这个示例（共享数据库服务器架构上的每个客户端的隔离数据库）到更复杂的分区数据方案。
此Microsoft文章包含有关方法和注意事项的有用概述：Multi-tenant SaaS database tenancy patterns。