我们的软件当前在MySQL上运行。所有租户的数据都存储在同一架构中。由于我们使用的是Ruby on Rails，因此我们可以轻松确定哪些数据属于哪个租户。但是，当然有些公司担心其数据可能会遭到破坏，因此我们正在评估其他解决方案。
到目前为止，我已经看到了三种选择：
我最喜欢Multi-Schema（考虑成本）。但是，创建一个新帐户并进行迁移似乎很痛苦，因为我将不得不遍历所有模式并更改其表/列/定义。
问： Multi-Schema似乎被设计为每个租户都有略微不同的表- 我不希望这样。是否有任何RDBMS允许我使用多模式多租户解决方案，其中所有租户之间共享表结构？
PS多指的是类似超级多（10.000+个租户）的东西。
但是，当然有些公司担心其数据可能会遭到破坏，因此我们正在评估其他解决方案。
这是不幸的，因为客户有时会误以为只有物理隔离才能提供足够的安全性。
有一篇有趣的MSDN文章，标题为Multi-Tenant Data Architecture，您可能需要检查一下。这就是作者如何解决对共享方法的误解：
一个普遍的误解认为，只有物理隔离才能提供适当级别的安全性。实际上，使用共享方法存储的数据也可以提供强大的数据安全性，但是需要使用更复杂的设计模式。
至于技术和业务方面的考虑，本文简要分析了某种方法可能比另一种方法更合适的地方：
您期望服务的租户的数量，性质和需求都会以不同的方式影响您的数据体系结构决策。以下某些问题可能会使您偏向于更孤立的方法，而另一些问题可能使您偏向于更共享的方法。 * 您希望定位多少个潜在租户？您可能无法凭一己之力来估计预期用途，但要考虑数量级：您是否正在为数百个租户构建应用程序？几千？成千上万？更多？您期望租户基数越大，您就越有可能考虑采用更共享的方法。 * 您希望普通租户的数据占用多少存储空间？如果您希望某些或所有租户存储大量数据，则最好使用分离数据库方法。（实际上，数据存储要求可能仍然迫使您采用单独的数据库模型。如果是这样，从一开始就以这种方式设计应用程序比以后再采用单独的数据库方法要容易得多。） 您希望普通租户支持多少个并发最终用户？数量越大，越能满足最终用户要求的方法越合适，越孤立。 您是否希望提供任何按租户的增值服务，例如按租户的备份和还原功能？通过更隔离的方法更容易提供此类服务。
您期望服务的租户的数量，性质和需求都会以不同的方式影响您的数据体系结构决策。以下某些问题可能会使您偏向于更孤立的方法，而另一些问题可能使您偏向于更共享的方法。
* 您希望定位多少个潜在租户？您可能无法凭一己之力来估计预期用途，但要考虑数量级：您是否正在为数百个租户构建应用程序？几千？成千上万？更多？您期望租户基数越大，您就越有可能考虑采用更共享的方法。
* 您希望普通租户的数据占用多少存储空间？如果您希望某些或所有租户存储大量数据，则最好使用分离数据库方法。（实际上，数据存储要求可能仍然迫使您采用单独的数据库模型。如果是这样，从一开始就以这种方式设计应用程序比以后再采用单独的数据库方法要容易得多。）
您希望普通租户支持多少个并发最终用户？数量越大，越能满足最终用户要求的方法越合适，越孤立。
您是否希望提供任何按租户的增值服务，例如按租户的备份和还原功能？通过更隔离的方法更容易提供此类服务。
更新： 进一步更新预期的租户数量。
对于大多数（如果不是全部）场景，预期的租户数量（10k）应该排除多数据库方法。我认为您不会喜欢维护10,000个数据库实例，每天都必须创建数百个新实例的想法。
仅从该参数来看，似乎最适合共享数据库单模式方法。每个租户将仅存储大约50Mb的事实，并且没有每个租户的附加组件，这一事实使这种方法更加合适。
上面引用的MSDN文章提到了三种安全模式，这些模式解决了共享数据库方法的安全注意事项：
如果您对应用程序的数据安全措施充满信心，则可以为客户提供服务级别协议，以提供强有力的数据安全保证。在SLA中，除了保证之外，您还可以描述将要采取的确保数据不被破坏的措施。
更新2： 显然，Microsoft伙计们移动/撰写了有关此主题的新文章，原始链接不见了，这是新链接：多租户SaaS数据库租用模式（对Shai Kerer表示感谢）
