我正在使用ZF编写一款PHP应用程序。客户将使用它向最终客户销售产品。客户可以将其应用程序托管在我的服务器上，也可以使用自己的服务器。其中大部分客户将在我的服务器上托管此应用程序。
我可以为所有客户设计一个数据库，因此每个客户都将使用相同的数据库，但当然产品等将分配给特定客户。这很简单。
我可以为每个客户使用单独的数据库，以使数据库结构更简单。然后，我可能会使用单独的子域和甚至文件位置，但那只是一个细节问题。
哪种解决方案具有更好的性能，差别有多大？您会选择哪种方案？
PHP中一个应用程序的多个客户端使用一个数据库还是多个数据库？
5
- prostynick
3
我没有一个关于你应该做什么的详细解释，但是你不应该创建多个本质上是重复的数据库。原因在于推出更新/错误修复变得非常困难，会导致碎片化和支持遗留系统。这些都是将阻止未来有效开发的额外开销。 - User123342234
@John Stuart。但它们基本上都是应用程序的独特实例，因此它们应该有自己的数据库。如果您有10个Magento电子商店，它们都将拥有自己的数据库。您不会把它们全部放在一个数据库中吧？一个客户端泄露了登录数据库服务器的详细信息，所有客户的数据都将受到影响。 - Richard Knop
1+1 开始引发观点争议。:) 这个问题相当复杂。它取决于太多微小的因素，没有一种万全之策的答案。 - Darryl E. Clarke
5个回答
5
我建议为每个客户使用单独的数据库。这样备份和扩展会更容易。如果您有一个大客户需要对架构进行一些自定义更改，您可以轻松完成。
如果某个客户需要您恢复其数据，则使用单个数据库很容易。在共享数据库上，这将更加困难。
如果大客户的流量增加了，您可以轻松地将其放在另一台服务器上，只需进行最小的更改。
如果有一个站点被攻击，您不会把所有人的数据都放在一个地方，损坏仅限于被黑客入侵的站点。
如果可能的话，我肯定会建议每个客户都使用一个数据库。
如果某个客户需要您恢复其数据，则使用单个数据库很容易。在共享数据库上，这将更加困难。
如果大客户的流量增加了，您可以轻松地将其放在另一台服务器上，只需进行最小的更改。
如果有一个站点被攻击，您不会把所有人的数据都放在一个地方，损坏仅限于被黑客入侵的站点。
如果可能的话，我肯定会建议每个客户都使用一个数据库。
- Byron Whitlock
4
4如果你有一百万客户、一百万个数据库和一百万乘以N个表格，那么会变得复杂而难以管理。如果出现这种情况，你会怎么做？ - Ish
2当你拥有一百万客户时，向SAP出售。 - RC_Cleland
1@Ish Kumar：换句话说，您建议使用相同的数据库来运行1000000个电子商店？您疯了吗？ - Richard Knop
2+1 我不明白为什么这个答案被踩了这么多次。 - Richard Knop
2
个人而言，我会选择多个数据库——即每个客户一个数据库。据我所知，所有客户都将使用您的应用程序实例，因此这些实例应该有自己的数据库。
如果您选择单个数据库，则会创建潜在的安全风险。一个客户端破坏了db服务器的登录详细信息，就会自动破坏所有客户的数据。
此外，单个安全漏洞（SQL注入攻击）可能会摧毁所有客户的数据（有了多个数据库，您仍然可以有时间修复安全漏洞并发布补丁，然后再攻击其他站点）。
您不希望拥有1000000个愤怒的客户，而不是1个愤怒的客户。
多个数据库还为您提供了更大的负载平衡可能性（您可以将数据库分布在更多的服务器上）。
如果您选择单个数据库，则会创建潜在的安全风险。一个客户端破坏了db服务器的登录详细信息，就会自动破坏所有客户的数据。
此外，单个安全漏洞（SQL注入攻击）可能会摧毁所有客户的数据（有了多个数据库，您仍然可以有时间修复安全漏洞并发布补丁，然后再攻击其他站点）。
您不希望拥有1000000个愤怒的客户，而不是1个愤怒的客户。
多个数据库还为您提供了更大的负载平衡可能性（您可以将数据库分布在更多的服务器上）。
- Richard Knop
1
+1 赞同。一个单一实例的安全性影响不可低估。 - Byron Whitlock
1
从某种程度上说，这是一个个人意见问题。两种模型都有优缺点。
个人而言，考虑到“他们可以使用自己的”评论，我会选择每个客户一个单独的数据库。这样做会带来以下好处：
- 可以在必要时移动客户数据。例如，根据负载情况将单个客户转移到其他服务器/设置上。 - 如果出现问题，只会影响一个客户，而不是所有人。 - 如果需要，可以将DB负载分散到多个DB服务器上。 - 如果客户有特定需求，您可以更轻松地为此提供服务，而不会影响其他客户。
从性能角度来看，老实说，我认为两种模型都没有真正的性能增益。当然，这当然取决于您的数据库结构和运行硬件。
个人而言，考虑到“他们可以使用自己的”评论，我会选择每个客户一个单独的数据库。这样做会带来以下好处：
- 可以在必要时移动客户数据。例如，根据负载情况将单个客户转移到其他服务器/设置上。 - 如果出现问题，只会影响一个客户，而不是所有人。 - 如果需要，可以将DB负载分散到多个DB服务器上。 - 如果客户有特定需求，您可以更轻松地为此提供服务，而不会影响其他客户。
从性能角度来看，老实说，我认为两种模型都没有真正的性能增益。当然，这当然取决于您的数据库结构和运行硬件。
- MrEyes
2
起初，我打算（现在仍然打算）使用一个大型数据库。当我向我的上级展示图表时，他看了一眼并说：“嗯...我以为我们会为此使用多个数据库”。之后，我开始思考这个想法如何能够带来更清晰的代码和更好的客户端分离。毕竟，一个愚蠢的“DELETE FROM”语句可能会导致只有一个客户端想杀死我，而不是所有客户端 ;) - prostynick
有许多方法可以保护免受“DELETE FROM”攻击，比如常规备份，使用像cakephp、zend这样的强大框架。 - Ish
1
就性能而言，你基本上是从“分片”方法开始的。因此，分片性能策略将变得轻而易举。
缺点是你可能会争论说你在复制中失去了一些（未定义的）开销。
一个陷阱是你可能无法及时注意到主要组件的性能问题。这是因为它们如此分散，所以可能不会出现在你的雷达上。负载测试是解决这个问题的方法。
- Evert
1
肯定支持螺母和螺栓：只需进行负载测试并查看即可！ - zanlok
-1
不要选择多个数据库的解决方案，如果一个数据库可以满足您的需求。因为在长期运行中，多个数据库会导致巨大的负担，随着您的业务增长，系统将变得高度复杂和难以管理。
使用适当的关系可以走得更远。
客户模型可以拥有多个产品，为什么需要多个数据库？
性能可以通过任何一种方式实现，只是使用多个数据库并不能从这个方向上获益。
使用适当的关系可以走得更远。
客户模型可以拥有多个产品，为什么需要多个数据库？
性能可以通过任何一种方式实现，只是使用多个数据库并不能从这个方向上获益。
- Ish
2
但他在谈论让所有客户使用同一个数据库。想象一下，1000个电子商店使用同一个数据库。那就太混乱了。每个商店都应该有自己的数据库。当然，它们应该具有相同的模式。您也不会在单个WordPress数据库中托管1000个博客。 - Richard Knop
1@Richard，问题在于很快就会变得难以管理，而在客户表中有1000条记录和产品表中有1000*100条记录也是可以的。他没有充分的理由去使用多个数据库。 - Ish
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接