多租户轨道应用：不同技术的优缺点是什么？

我最初为一个客户端编写了Ruby on Rails应用程序。 现在，我正在更改它，以便它可以用于不同的客户端。 我的最终目标是某些用户（不是我）可以单击按钮并创建新项目。 然后生成所有必要的更改（新模式，新表，代码处理），而无需任何人需要我编辑database.yml文件或添加新的模式定义。 我目前正在使用SCOPED访问。 所以我有一个项目模型，其他相关模型有一个project_id列。

我已经查看了有关Rails中多租户应用程序的其他post。 很多人似乎建议为Postgres中的每个新客户创建不同的架构。 但是，对于我来说，对于新客户端而言，在数据模型方面具有不同的模式并没有多大帮助。 每个客户端将具有相同的表，行，列等。

我对每个客户的愿景是我的生产数据库首先有一个不同项目/客户的表。 并且这些表中的每一个都链接到一组表，这些表对于不同的数据几乎相同。 换句话说，表格。 或者换句话说，第一个表将映射到具有相同结构的每个客户端的不同数据集。

我解释我的愿景的方式与Postgres实现不同“模式”的方式类似吗？ 它看起来像嵌套表吗？ 或者Postgres是否必须查询数据库中的所有信息？ 我目前不使用Postgres，但我愿意学习它是否适合设计。 如果您知道使用适合我需求的Rails的数据库软件，请告诉我。

现在，我正在使用范围来完成多租户应用程序，但它不会感觉可扩展或干净。 但是，如果我给他们提供可填写的信息，它确实使非技术用户很容易创建新项目。 你是否知道在多用户模式Postgres定义是否可以让用户点击按钮后自动工作？ 我希望这可以由Rails处理，如果可能的话不是由外部脚本处理？ （请以任何方式提出建议）

最重要的是，您是否建议使用任何插件，或者我应该为此任务采用不同的框架？ 我发现Rails在某些抽象情况下受到限制，这是我第一次遇到Rails扩展问题。

任何与多租户申请或我的情况有关的建议都是受欢迎的。 如有任何问题需要澄清或提供其他建议，也欢迎。

谢谢， – 戴夫

Answer 1

不要忘记使用默认范围，同时按照现在的方式创建命名scops，它确实感觉可以做得更好。 几个月前，我遇到了Samuel Kadolph关于这个问题的指南 ，看起来它可以很好地适应你的情况，并且有利于保持你的应用程序不受某些PgSQL特性的影响。

基本上，他描述设置应用程序的方式包括向应用程序添加tennants的概念，然后使用它在查询时使用数据库对数据进行范围调整。

Answer 2

MSDN 对多租户数据架构有很好的介绍 。

在频谱的一端，每个租户有一个数据库（“无共享”）。 “无共享”使灾难恢复变得非常简单，并且在租户之间具有最高程度的隔离。 但它也是每个租户平均成本最高的，它支持每台服务器最少的租户。

在频谱的另一端，您将租户ID号存储在每个共享表的每一行中（“共享所有内容”）。 “共享一切”使灾难恢复变得困难 – 对于单个租户，您必须在每个共享表中仅恢复一些行 – 并且它具有最低程度的隔离。 （格式错误的查询可以公开私有数据。）但它的每个租户的成本最低，并且它支持每个服务器的租户数量最多。

我对每个客户的愿景是我的生产数据库首先有一个不同项目/客户的表。 并且这些表中的每一个都链接到一组表，这些表对于不同的数据几乎相同。 换句话说，表格。 或者换句话说，第一个表将映射到具有相同结构的每个客户端的不同数据集。

这听起来像是在谈论每个租户的一个架构。 密切关注权限（SQL GRANT和REVOKE语句。以及ALTER DEFAULT PRIVILEGES 。）

Answer 3

多租户有两个使用范围和子域的轨道广播，另一个用于处理多个模式 。

还有multitenant gem可以帮助你的范围和公寓gem处理多个模式。

这里也是关于multitenancy-with-rails的一个很好的演示。