有很多数据库的问题？

Question

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

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

有很多数据库存在问题，比如数千个（目前大约有20个）？它有很多优点：分离安全性，可扩展性，轻松提取客户特定数据（也是可扩展性的一部分）等。

Answer 1

我可以看到两个问题：

维护 - 如果您有数千个数据库，那么对数据库进行更改（更改表结构，修改SP等）会很麻烦。当然，你可以编写更改脚本，但许多数据库是更多的机会出错。如果您的脚本中途失败，而您的左侧有一些具有更改的数据库而某些数据库没有更改，那么您打算做什么？另外，正如另一张海报所提到的，连接字符串，登录/密码等内容的维护是什么？

资源 - 我不确定数据库的每个实例使用哪些资源，但运行那么多数据库需要一些开销。如果您将其拆分为多台计算机，则会再次遇到上述维护问题。

Answer 2

我同意TLiebe的意见，在未来的维护中，如果不是成千上万的数据库，将会非常难以处理。

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

MySpace已经将这个概念用于他们的数据库设置，到目前为止似乎非常成功。关于MySpace's Architecture 的文章。

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

Answer 3

我可以理解关于心灵安宁和可扩展性的论点，即使可能没有坚硬的“证据”来支持它。表格更改等维护任务可以轻松实现自动化。数据库错误或入侵将包含在一个客户中，将数据库移动到另一个服务器可以轻而易举地完成。

另一方面，该模型的批评者可能有一个观点。

为什么不试试呢？设置一个单独的凭据系统，复制您的数据库10.000次，并查看开销和性能是否仍然是o.k.

Answer 4

我认为您的设计存在问题。而不是在一个数据库中有一组表，为什么每个客户使用一个数据库？到目前为止，我看到你提到的优势，我可以看到使用许多数据库的巨大开销.. +连接字符串+单独的凭据。

Answer 5

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

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