Rails Basecamp 风格子域最佳实践
我的目标是为每个子域拥有单独的用户帐户。在任何情况下，我都不想在子域之间进行异花授粉。
我查看了 Robby Russle 和 DHH 想法（虽然都是 Rails3 之前的版本）。
控制器处理非常简单，我的问题是如何保持模型的数据分离。阻止 user1 查看 user2 数据的最佳方法是什么？
一些想法可能包括：
为每个模型添加一个
subdomain_id外键 - 优点，简单的一对多关系可用于将每个模型的范围限定为子域。 - 缺点，数据和更大的应用程序逻辑之间的耦合非常紧密，这似乎不合适。一对多 :through每个模型将其与子域关联 - 优点，无需添加subdomain_id外键列到现有表中，将它们与其子域相关联。 - 缺点，我的直觉是这太过分了。多个联接查询可能会变得复杂，并且可能会出现交叉授粉错误。每个子域都有独立的应用程序或数据库 - 优点，数据完全隔离。 - 缺点，需要管理/更新/保护/托管/等大量单独的应用程序/数据库。
你的想法？
My goal is to have separate user accounts for each subdomain. Under no circumstance do I want cross-pollination between subdomains.
I've looked over Robby Russle, and DHH's thoughts (both are pre-Rails3 though).
The controller handling is pretty straight forward, my questions is about keeping the model's data separated. What's the best way to keep user1 from seeing user2's data?
Some idea's might include:
Add a
subdomain_idforeign key to every model - Advantage, simple one-to-many relationship can be used to scope each model to a subdomain. - Disadvantage, this is pretty tight coupling between the data and the larger application logic, which seems inappropriate.One-to-many :throughfor each model associating it with a subdomain - Advantage, no need to add asubdomain_idforeign key column to existing tables associating them with their sub domain. - Disadvantage, My gut feeling is that this is way overkill. Multiple join queries may get complicated and cross-pollination bugs may occur.Separate applications or databases for each subdomain - Advantage, the data is completely segregated. - Disadvantage, a large number of individual applications/databases will need to be managed/updated/secured/hosted/etc.
Your idea?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
选项 5。Guy Naor 的架构解决方案 - 优势，这让我大吃一惊。大多数情况下对 Rails 是透明的，完全的数据分离，只有一个数据库，非常适合最初不是设计为多租户的应用程序。惊人的。 - 缺点，需要使用 Postgres 或其他支持模式的数据库（无论如何我已经在使用 PG），迁移时需要迭代现有模式。
目前看来，这无疑是最好的方法。有什么重大缺点吗？
Option 5. Guy Naor's Schema solution - Advantage, This just blew my mind. Mostly transparent to rails, COMPLETE data separation, only one database, works really great for applications that weren't originally designed as multi-tenant. a-mazing. - Disadvantage, need to be using Postgres, or some other database that supports schemas (I'm already using PG anyway), you'll need to iterate over existing schemas when you migrate.
Right now this seems far and away the best way. Are there any major drawbacks?.
如果您确定对象与子域的关系始终是一对一的，我会选择选项 1。如果对象将来可能与多个子域相关，则必须选择选项 2。它会产生更多开销，但使用康康舞之类的东西时很容易管理。
由于你提到的原因，我会远离选项 3。 Rails 不能很好地处理多个数据库，此外，在一个应用程序中使用多个数据库并不能保证比其他选项更高的安全性。
If you're sure the object-to-subdomain relation will always be one-to-one, I would pick option 1. If objects might be related to multiple subdomains in the future you're bound to option 2. It incurs more overhead, but it's easily managed when using something like cancan.
I would stay away from option 3 for the reasons you mentioned. Rails doesn't do multiple databases well and besides, using multiple databases in one application doesn't guarantee any more security than the other options.