Php 有很多数据库的问题？

我们构建了一个托管的web应用程序，它的开发方式是每个客户都连接到一个单独的数据库。这个应用程序是一个web平台/发布系统，到目前为止，它在这个设计中工作得非常好。我们还有一个主数据库

现在我们将对我们的定价模式进行一些修改，引入免费账户。这将（希望）产生更多的客户

---

拥有大量数据库（比如数千个）是否有问题（目前大约有20个）？它有很多优点：通过分离实现的安全性、可扩展性、轻松提取特定于客户的数据（也是可扩展性的一部分）等等。

我认为您的设计存在问题。与其在一个数据库中有一组表，为什么要为每个客户使用一个数据库？就我所看到的您提到的优点而言，我可以看到使用许多数据库会带来很大的开销..+连接字符串+单独的凭据。

我可以看到两个问题：

维护—如果您有数千个数据库，那么更改数据库（更改表结构、修改SP等）将是一件痛苦的事情。当然，您可以编写更改脚本，但如此多的数据库意味着出错的可能性要大得多。如果你的脚本中途失败了，剩下一些数据库有更改，而有些数据库没有更改，你该怎么办？另外，正如另一张海报所提到的，如何维护连接字符串、登录/密码等

---

资源-我不确定数据库的每个实例使用什么资源，但运行这么多数据库需要一些开销。如果你把它分成几台机器，你会再次遇到上面提到的维护问题。

我同意TLiebe的观点，在未来，如果没有数千个数据库的话，维护将非常困难

更好的解决方案可能是按目的而不是按用户对数据库进行分区。您可以将配置文件、内容、站点等作为逻辑分区，然后将每个分区上的用户数限制为一定数量。然后继续使用profile1和profile2，直到用户用完为止。通过这种方式，您可以将数据分散在多台不同的机器上，但仍然可以通过功能将它们关联起来

MySpace在他们的数据库设置中使用了这个概念，到目前为止似乎非常成功。关于……的文章

---

祝你好运，希望这能有所帮助。

我能理解关于心态平和和和可伸缩性的争论，尽管可能没有确凿的“证据”支持它。像表格更改这样的维护任务可以很容易地自动化。数据库错误或入侵将被包含在一个客户中，将数据库移动到另一个服务器可以轻松完成

另一方面，该模式的批评者可能有其观点

---

为什么不干脆试试呢？设置一个单独的凭据系统，复制数据库10.000次，然后查看开销和性能是否仍然正常。

如前所述，可以编写数据库维护（包括安全性）脚本（如何执行取决于您的数据库服务器）

---

在这个场景中，您实际上也获得了可伸缩性。原因是，当负载变得太大时，您可以添加另一台服务器，并将一部分数据库移动到新服务器。无需重新设计应用程序。

明确；所有提到的优势都是关于内心的平静，没有真正的“硬”优势。只需在大多数记录中添加一个“用户”字段，并将它们全部放在同一个数据库中。如果一个客户端被黑客攻击，会发生什么情况？那么每个人的信息都是可用的。为什么不将它们保存在单独的数据库中，有单独的数据库用户，这样，如果一个客户被黑客攻击，他们都不会被黑客攻击呢？我相信两个单独的数据库比一个带有客户字段的表更安全。我真的错了吗？使用单独的数据库服务器，我们可以轻松地在服务器之间迁移客户，或者让客户“带走他们的数据库”。我们也可以通过转储数据库导出客户的数据，用于本地开发等。“+连接字符串+单独凭证”的“大开销”是什么？乔治，这似乎真的是倒退的逻辑。如果你的数据库服务器被黑客攻击，那么很有可能——不管怎样，你都完蛋了。@George Stocker：如果你说的“单独的数据库用户”，我同意，是指MySQL用户，那会增加安全性。我以后会调查的，谢谢！维护-有效点，尽管我们已经用DB结构迁移脚本覆盖了一半。到目前为止，这种方法效果很好，但我还没有计算出大量数据库的影响。特定于帐户的配置选项存储在XML文件中，这是一个问题吗？资源-这是我的问题，如果有开销和多少：-）我不知道每个数据库消耗多少。我建议您使用一台测试机，测量单个数据库的基线资源使用情况（确保它具有与典型客户相同的数据量、表等），然后编写一个脚本来制作几百个副本。比较前后的内存和CPU使用情况。这不会是一个很好的比较，因为您的测试数据库实际上没有被使用，但这只是一个开始。您将丢失磁盘I/O使用等信息，因为数据库实际上没有被使用。谢谢，有趣的阅读。但我不认为这对我们有什么好处，因为我们没有几十亿的用户：-）这感觉像是从两个团队中挑出了缺点，将所有客户的数据混合在一起并使用多个数据库。编写安全脚本是什么意思？呵呵，是的，当我写《职业选手》时，我意识到了这一点，但那将是更多的工作。谢谢，也许我应该这样做，如果没有人对这方面有任何经验，或者除了“必须有”以外的其他经验：