每个客户端一个数据库或所有客户端位于一个数据库中。我应该使用哪一个进行在线申请？
所以我有这个应用程序，它有多个模块，从项目管理到会计模块。 问题是我应该为每个客户（公司）拥有一个数据库还是一个包含所有内容的数据库？
1）哪一个性能更好？
2) 管理多个数据库会变得更加困难，或者这些数据库是否可以管理。
3) 我们将为所有用户提供相同的应用程序，这意味着无论数据库数量有多少，都将使用相同的模式。
4) 一些客户将拥有大量此类数据（例如，会计师每年可能在一个表中添加多达 200 万行），而其他客户将使用少得多的数据。
你认为我应该用什么？
So I have this application that would have multiple modules, from project management to accounting modules.
The question is should I have one database per client (company) or one database that holds everything ?
1) which one would be better performance wise?
2) is is going to be a lot harder to manage multiple databases or is these manageable.
3) We are going to have the same application for all users, meaning that the same schema is going to be used no matter the number of databases.
4) some clients are going to have a lot of that (accountants for example might have up to 2 million row added per year in one table) while others are going to use much much fewer data.
what do you think I should use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
1) 拥有独立的数据库可以更轻松地在多个主机上分配负载，它在很多方面提升了屋顶；磁盘、内存、锁定、CPU、备份时间等。如果您真的想在 mysql 中放入数百万行，那么使用单独的数据库（不仅是模式），甚至单独的实例当然是一个好主意，这样资源消耗型客户就不会给资源消耗较少的客户带来停机时间。
2) 管理起来会困难 N 倍，其中 N 是数据库的数量 :o) 您必须将这一额外成本与仅使用一个数据库/模式并在代码中管理客户分离的成本进行比较。如果您必须致电托管公司的客户支持，甚至是当地脾气暴躁的 dba，而不是每次需要更新架构或创建新数据库时从控制台运行一个简洁的脚本，那么从本质上讲，管理起来也会更加困难。
一些数据库和持久性框架支持多租户，Oracle 提供了此支持，并且 Hibernate 4 中开始出现支持。
尽管许多论点都指向单独数据库的方向，但通常可以使用也只有一个数据库。
1) Having separate databases allows for easier distribution of load on several hosts, it lifts the roof in many ways; disk, memory, locking, cpu, backup-time and so on. If you are serious about putting millions of rows in mysql, it is certainly a good idea with separate databases (not only schemas), and even separate instances, so that the resource-consuming customers won't impose downtime on less resource consuming ones.
2) It is going to be exactly N times harder to manage where N is the number of databases :o) This extra cost you must compare to the cost of using just one db/schema and instead manage separation of customer in code. It's also inherently much harder to manage if you have to call customer support at your hosting company, or even your local grumpy dba, instead of just running a neat script from your console each time you need to update schema or create a new database.
Some databases and persistence frameworks have support for multi-tenancy, Oracle has this and support is beginning to emerge in Hibernate 4.
Even though many arguments point in the direction of separate databases, it is generally possible to use just one database as well.
理论上，多个数据库的性能会更好。也就是说，如果您可以将它们放在单独的磁盘控制器上。但实际上它们很可能都位于同一磁盘上，因此可能不会有任何性能提升。此外，与可将数据卸载到的附加单独逻辑磁盘相比，附加磁盘更适合用作 RAID 阵列的附加成员。
从维护的角度来看，多个数据库将是一场噩梦。对数据库的每次更改都需要进行 N 次，其中 N 是客户端的数量。当然，您永远不会手动执行此操作，因此您始终必须以编程方式执行此操作，很快您就会开始意识到，如果您只需在管理控制台上单击几下即可执行相同的更改，而不是通过每次都必须编写代码来为您完成这些工作。
In theory, multiple databases will be better for performance. That is, if you could put them on separate disk controllers. But in actuality they will most probably all be on the same disk, so there will probably be no performance gain. Plus, additional disks are better utilized as additional members of RAID arrays than as additional separate logical disks to which you can offload data.
From the point of view of maintenance, multiple databases are going to be a nightmare. Every ALTERation to the database will need to be made N times, where N is the number of clients. Of course you will never do that by hand, so you will always have to do it programmatically, and pretty soon you will start appreciating how easy things would be if you could just do the same ALTERations with a few clicks on the management console instead of having to write code to do them for you every time.
如果您不使用单独的数据库，无论有任何其他问题，安全性将是一个真正的负担。您在编码时必须非常谨慎，以确保一家公司不会看到（或修改或删除）其他公司的数据。
security will be a real bear if you don't use separate databases, regardless of any other concerns. you would have to be extremely cautious with coding to make sure one company doesn't see (or modify or delete) the others' data.