一个或多个数据库，用于PHP中多个客户端的应用程序

我正在用ZF编写一个PHP应用程序。客户将使用它向最终客户销售他们的产品。客户将在我的服务器上托管他们的应用程序，或者他们可以使用自己的应用程序。他们中的大多数人将在我的服务器上托管此应用程序

我可以一次为所有客户设计一个数据库，这样每个客户都将使用相同的数据库，但当然产品等将分配给特定的客户。琐碎的

我可以为每个客户使用单独的数据库，因此数据库结构会更简单。然后我可能会使用单独的子域，甚至可能使用文件位置，但这只是一个细节

---

哪种解决方案的性能更好，差异有多大？你会选择哪一个？

在某种程度上，这是个人意见的问题。这两种模式各有利弊

就个人而言，由于“他们可以使用他们自己的”评论，我会为每个客户使用一个单独的数据库。这给你

• 在必要时移动客户数据的能力。例如，根据负载等情况将单个客户移动到不同的服务器/设置上
• 如果出现问题，您只影响一个客户，而不是所有人
• 如有必要，您可以在多个DB服务器上分散DB负载
• 如果客户向您提出特定要求，您可以更轻松地满足此要求，而不会影响其他客户

---

从性能的角度来看，老实说，我不认为这两种模式都有任何真正的性能提升。也就是说，这当然取决于数据库的结构及其运行的硬件。

我会为每个客户使用单独的数据库。它使备份和扩展更容易。如果您有一个大客户需要对模式进行一些自定义更改，那么您可以轻松地进行更改

如果一个客户需要您使用单个数据库恢复他们的数据，那么这很简单。在共享数据库上，这要困难得多

而且，如果大客户曾经获得大量流量，您可以轻松地将它们放到另一台服务器上，只需进行最小的更改

如果一个网站被入侵，你没有在一个地方为每个人提供所有的数据，损害只会减轻到被入侵的网站

---

如果可能的话，我绝对建议每个客户使用1 db。

如果一个数据库可以满足您的需求，请不要选择多个数据库解决方案。因为从长远来看，多个数据库将导致巨大的负担，并且随着您的发展，您的系统将变得非常复杂且难以管理

使用适当的关系，你可以走很长的路

一个客户机模型可以有许多产品//为什么要有多个数据库

---

性能可以通过任何一种方式实现，仅仅使用多个dbs都不会在这方面受益

从性能角度看，您基本上是从“分片”方法开始的。因此，分片性能策略将是小菜一碟

缺点是，您可能会争辩说，在复制过程中会损失一些（未定义的）开销

---

一个陷阱是，您可能不会很快注意到主要组件中的性能问题。这是因为它们非常分散，所以它们可能在你的雷达上看不到。负载测试是领先这一步的方法

就我个人而言，我会使用多个数据库，即每个客户都有一个数据库

据我所知，您的所有客户机将只使用应用程序的一个实例，因此这些实例应该有自己的数据库

如果只使用一个数据库，则会产生巨大的潜在安全风险。如果一个客户端将登录详细信息泄露到db服务器，则会自动泄露所有客户端的数据

此外，单个安全漏洞（SQL注入攻击）可能会破坏所有客户端的数据（对于多个dbs，您仍有时间修复安全漏洞并在所有其他站点受到攻击之前发布补丁）

你不想拥有一支由100万疯狂客户组成的大军，而不是一个愤怒的客户

---

多个数据库还为您提供了更大的负载平衡可能性（您可以让dbs分布在更多服务器上）。

如果您有1000000个客户端，您会怎么做？1000000个数据库和1000000个Xn表。当你把1000000个客户卖给你的时候，它将变得复杂和难以管理SAP@Ish库马尔：换句话说，你建议1000000个电子商店都使用同一个数据库？你疯了吗？+1我不明白为什么这个答案被否决了这么多次。起初，我打算（现在仍然）拥有一个大数据库。当我把这个图表交给我的上司时，他看了看，说：“嗯……我想，我们将为此建立多个数据库。”。在那之后，我开始思考这个想法如何能使代码更清晰，客户之间的分离更好。毕竟，从中删除一个愚蠢的

会导致这样的情况，即只有一个客户希望杀死我，而不是所有客户；）有很多方法可以防止
从
中删除，比如例行备份，使用cakephp、ZendDefinitly+1等健壮的框架进行保护：只需对其进行加载测试，然后查看！我没有一个大的详细解释，你应该做什么，但你不应该做的是创建多个基本上是重复的数据库。原因是，推出更新/错误修复变得非常困难，从而造成碎片和支持遗留问题。这些都是会妨碍未来高效开发的开销。@johnstuart。但它们基本上都是应用程序的唯一实例，因此它们应该有自己的数据库。如果你有10个Magento eShop，他们都会有自己的数据库。你不打算把它们都放在一个数据库里吗？一个客户端泄露数据库服务器的登录详细信息，所有客户端的数据都将泄露。+1 f