Rails Web 应用程序：是否为每个打开的帐户创建一个单独的数据库？
我即将完成构建一个简单的基于订阅的支持票证 Web 应用程序。我正在设置授权。但由于这将是我自己要部署的 Web 应用程序，所以我对此感到好奇。
您是否为每个开设的帐户创建一个单独的数据库？
假设您有此支持票证 Web 应用程序。您只有一位帐户所有者。帐户所有者可以设置可以响应支持票证的代理。此外，还有一些客户角色可以打开支持票证。
正如您所看到的，数据库将包含用户、支持票证等。
最好的方法是什么？
1）为整个应用程序创建一个数据库？这样，每次有人注册时，所有内容都会与其他票证和用户数据以及其他所有内容一起添加到同一个数据库中，或者...
2) 每次有人注册时，为每个帐户订阅创建一个单独的数据库。
我认为出于安全和数据完整性的目的，选项 2 可能是最佳选择。如果是这样，您是如何解决这个问题的？
I'm about to finish building a simple subscription based support ticket Web app. I'm setting up authorization. But since this it's going to be my very own Web app that I'm going to deploy I'm wondering about this.
Do you create a separate database per account opened?
Let's say you have this support ticket Web app. You have ONE and ONLY ONE account owner. Account owner can setup agents that can respond to support tickets. Also, there are customer roles that open support tickets.
So as you can see the database will contain users, support tickets and more.
What is the best way to go?
1) Create one database for the whole application? That way every time somebody signs up, everything is added to the same database with the other tickets and users data and everything else or...
2) Everytime someone signs up, create a separate database per account subscription.
I'm thinking that maybe option number 2 would be a best choice for security and data integrity purposes. If so, how have you gone about tackling this issue?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
听起来你想要的是多租户：
这篇文章虽然有点过时，但它是我将如何去做的总体思路。 Simple Rails 多租户。它干净、高效，可以让您免于编写不需要的代码。
It sounds like what you want is Multitenancy:
This article while a little dated is the general idea of how I would go about doing it. Simple Rails Multi-Tenancy. It's clean and efficient and saves you from writing code that you don't need to.
你应该选择选项#1。第二个（几乎（可能在某些情况下它是好的，但我目前找不到））永远不是一种选择。
出于安全目的（嗯，在某种意义上），您是正确的，但它也会产生许多您必须考虑的其他问题。
为每个用户拥有不同的数据库意味着对于每个请求（请记住，HTTP 是无状态的），您将必须打开一个到数据库的新连接，执行任何需要执行的操作，然后再次关闭连接，而不是使用 Rails 中的连接池。这对性能影响很大。
数据库越多，管理就会越麻烦。此外，在服务器上拥有多个数据库确实需要更多的资源，而不仅仅是一个更大的数据库。
您必须绕过 Rails 中的整个连接处理，因为通常每个应用程序都有一个数据库。更改特定模型的数据库很容易，但它增加了可能出错的额外位置。
Rails 确实具有在同一数据库中确定范围和处理分离数据的良好功能，仅适用于您提到的那种用例。
You should go for option #1. Number 2 is (almost (there are probably cases where it is good, but I can't find one at the moment)) never an option.
You are right in security purposes (well, in a sense), but it also creates a lot of other problems that you will have to think about.
Having a different database for each user means that for each request (remember, HTTP is state-less) you will have to open up a new connection to the database, do whatever needs to be done and then close the connection again, instead of using the connection pooling that is in Rails. This affects the performance a great deal.
Administration will be a hassle the more databases you have. Also, having multiple databases on a server do require more resources than just a bigger database.
You would have to circumvent the entire connection handling in Rails since there it is usually one database per application. It is easy to change the database for specific models, but it adds additional places where things can go wrong.
Rails do have good functionality for scoping and handling of separating data within the same database, just for that kind of use-case that you are mentioning.