SaaS 应用程序是如何组织的？
考虑将多个客户端的 Web（MVC，例如 Rails）应用程序作为服务。
这个要怎么设计呢？
每个客户端一个应用程序实例？ （+ 每个客户端一个数据库）
所有客户端一个实例（+所有客户端一个数据库）
前一个很简单，但是......“效率低下”。后者怎么样？ （最佳实践、设计模式）如何分离客户端数据？例如：客户“1”的工人“A”有两个文档，客户“2”的工人“B”有三个文档。如何建立模型关联来保护其他用户（和客户端）数据？我认为将每个查询与客户端模型结合起来并不是一个好的解决方案。
Consider web (MVC, for example Rails) application for multiple clients as a service.
How to design this?
one application instance per client? (+ one database per client)
one instance for all clients (+ one database for all clients)
Former one is simple, but... "inefficient". How about the latter? (best practices, design patterns) How to separate client data? For example: worker "A" of client "1" has two documents, worker "B" of client "2" has three documents. How to build model associations to protect other users (and clients) data? I think joining every query with Client model is not a good solution.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我建议查看早期对 Ruby on Rails 中的多租户应用程序的响应。
这实际上取决于您的用例，但处理此问题的最简单方法是使用范围仅限于特定应用程序的单个数据库。您可以根据您的要求/预算从那里出发。
我是该链接中详细介绍的 postgresql 模式系统的忠实粉丝：P
I would suggest having a look at an earlier response on multi-tenant apps in Ruby on Rails.
It really depends on your use case, but the simplest way to handle this is a single database with scoping to particular applications. You can head from there depending on your requirements/budget.
I am a big fan of the postgresql schema system detailed in that link :P
这篇 MSDN 文章很好地解释了多租户数据架构。
可能很明显，但无论如何我都会注意到； Rails 实例的默认配置是在 cookie 中存储客户端会话信息，这有助于让所有应用程序实例同样能够为请求提供服务。
本系列中的另一篇文章在识别共享服务（例如作为您需要的监控。
This MSDN article explains multi-tenant data architectures well.
Probably obvious but I'll note it anyway; the default configuration of Rails instances to store session information client-side in cookies lends itself to having all application instances equally able to service requests.
Another article in the series is also informative in terms of identifying shared services such as monitoring that you will need.