PHP 中为多个客户端应用的一个或多个数据库
我正在 ZF 中编写 PHP 应用程序。客户将用它来将他们的产品销售给最终客户。客户将在我的服务器上托管他们的应用程序，或者他们可以使用自己的服务器。他们中的大多数人都会在我的服务器上托管此应用程序。
我可以同时为所有客户设计一个数据库，因此每个客户都将使用相同的数据库，但当然产品等将分配给特定的客户。琐碎的。
我可以为每个客户使用单独的数据库，因此数据库结构会更简单。然后，我可能会使用单独的子域，甚至可能使用文件位置，但这只是一个细节。
哪种解决方案的性能更好？差异有多大？你会选择哪一个？
I am writing a PHP application in ZF. Customers will use it to sell their products to final customers. Customers will host their application on my server or they could use their own. Most of them will host this application on my server.
I could design one database for all customers at once, so every customer will use the same database, but of course products etc. will be assigned to particular customer. Trivial.
I could use separate database for every customer, so the database structure will be simpler. I will then probably use separate subdomains and maybe even file location, but that is just a detail.
Which solution will have better performance and how big will be the difference? Which one would you choose?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我会为每个客户使用单独的数据库。它使备份和扩展变得更加容易。如果您的大客户需要对架构进行一些自定义更改，您可以轻松完成。
如果一位客户需要您恢复他们的数据，使用单个数据库就很简单了。在共享数据库上，要困难得多。
如果大客户获得大量流量，您可以轻松地将它们放在另一台服务器上，只需进行最少的更改。
如果一个站点遭到入侵，您无法在一处拥有每个人的所有数据，因此只会减轻被黑客攻击的站点的损害。
如果可能的话，我绝对建议每个客户使用 1 db。
I would use a separate database for each customer. It makes backup and scaling easier. If you ever get a large customer that needs some custom changes to the schema, you can do it easily.
If one customer needs you to restore their data, with a single database it is trivial. On a shared db, much harder.
And that if large customer ever gets a lot of traffic, you can easily put them on another server with minimal changes.
If one site gets compromised, you don't have all of teh data for everyone in one place, the damage is mitigated to just the site that was hacked.
I'd definitely recommend going with 1 db per customer if possible.
就我个人而言，我会使用多个数据库 - 即每个客户端都有一个数据库。
据我了解，您的所有客户都将仅使用您的应用程序的一个实例，因此这些实例应该有自己的数据库。
如果您使用单个数据库，则会造成巨大的潜在安全风险。一个客户端泄露数据库服务器的登录详细信息将自动泄露所有客户端的数据。
此外，单个安全漏洞（SQL 注入攻击）可能会破坏所有客户端的数据（使用多个数据库，您仍然有时间修复安全漏洞并在所有其他站点受到攻击之前发布补丁）。
你不想拥有一支由 1000000 名愤怒的客户组成的大军，而不是只有 1 个愤怒的客户。
多个数据库还为您提供了更大的负载平衡可能性（您可以将数据库分布在更多服务器上）。
Personally, I would go with multiple databases - i.e. a database for each client.
As I understand it all your clients will be using just an instance of your application so these instances should have their own databases.
If you go with a single database, you are creating a great potential security risk. One client compromising the login details to the db server would automatically compromise data of all your clients.
Also a single security vulnerability (a SQL injection attack) could destroy data of all clients (with multiple dbs you could still have time to fix the security hole and release a patch before all other sites are attacked).
You don't want to have an army of 1000000 mad clients instead of just 1 angry client.
Multiple databases also give you a greater possibility of load balancing (you can have the dbs spread across more servers).
在性能方面，您基本上是从“分片”方法开始的。正因为如此，分片性能策略将是小菜一碟。
缺点是您可能会认为在复制过程中损失了一些（未定义的）开销。
一个陷阱是您可能不会很快注意到主要组件的性能问题。这是因为它们非常分散，因此您的雷达上可能看不到它们。负载测试是解决这个问题的方法。
Performance wise you're basically start with a 'sharding' approach. Because of this, the sharding performance strategy will be piece of cake.
The downside is that you could argue you're losing some (undefined) bit of overhead in the duplication.
One pitfall is that you might not notice performance issues in major components as quickly. This is because they are so scattered, so they might not be visible on your radar. Load testing is the way to get ahead of this.
在某种程度上，这是个人意见的问题。两种模型都有优点和缺点。
就个人而言，由于“他们可以使用自己的”评论，我会为每个客户使用单独的数据库。这使您
从性能角度来看，说实话，我认为这两种模型都没有任何真正的性能提升。也就是说，这当然取决于数据库的结构及其运行的硬件。
To some extent this is a question of personal opinion. There are pros and cons of both models.
Personally, and because of the "they could use their own" comment, I would go with a seperate database per customer. This gives you
From a performance perspective, to be honest I don't think there is any real performace gain in either model. That said this does of course depend on the structure of your DB and the hardware it runs on.
如果一个数据库可以满足您的需求，请不要选择多数据库解决方案。因为多个数据库会导致长期的巨大负担，并且随着您的成长，您的系统将变得高度复杂且难以管理。
运用正确的关系，你可以走得更远
性能可以通过任何一种方式实现，仅仅使用多个数据库不会在这个方向上受益
Don't choose multiple databases solution, if your needs can be fulfilled with one database. Because multiple databases will lead to big burden in long run, and your system will become highly complicated and unmanageable as you grow.
Using proper relationship you can go long way
Performance can achieved in either ways, just going multiple dbs will NOT benefit in that direction