我目前正在与同事讨论有关我们正在创建的PHP Web应用程序的数据库设计的最佳实践。该应用程序专为企业而设计，每个注册的公司都会有多个用户使用该应用程序。
我的设计方法是为每个注册的公司创建一个新的数据库。这样一切都是沙盒，模块化和小型。我的同事哲学是将每个人都放在一个数据库中。他的论点是，如果我们有1000多家公司注册，我们最终会有1000多个数据库来处理。更不用说做商业智能的混乱了。
为了举例，假设应用程序是订单输入系统。使用单独的数据库，即使每家公司每天执行100多个订单，表格大小也可以保持可管理。在单桶应用程序中，表格可以非常快速地变大。
这是最好的做法吗？我尝试在网上打猎，但没有取得多大成功。链接，白皮书和演示文稿欢迎。
提前致谢，
The1Rob
答案 0 :(得分：24)
我与WordPress托管服务wordpress.com的数据库架构师进行了交谈。他说他们从一个数据库开始，一起托管所有客户。毕竟，单个博客网站的内容确实不是那么多。按理说，单个数据库更易于管理。
这对他们来说效果很好，直到他们有成百上千的客户，他们意识到他们需要横向扩展，运行多个物理服务器并在每台服务器上托管其客户的子集。当他们添加服务器时，将单个客户迁移到新服务器很容易，但更难分离属于单个客户博客的单个数据库中的数据。
随着客户来来往往，一些客户的博客有大量活动而有些客户过时，多台服务器的重新平衡成为一项更加复杂的维护工作。监控每个数据库的大小和活动也很容易。
同样地，对包含数据数据的单个数据库进行数据库备份或恢复，而不是单个数据库备份和每个数兆字节的恢复，这是一个重要因素。考虑一下：客户打电话说他们的数据由于一些不良数据输入而得到了SNAFU，您能否从昨天的备份中恢复数据？如果所有客户共享一个数据库，您将如何恢复一个客户的数据？
最终他们决定将每个客户分成单独的数据库，虽然管理起来很复杂，但却为他们提供了更大的灵活性，并且他们将托管服务重新构建到此模型中。
因此，从数据建模的角度来看，将所有内容保存在单个数据库中似乎是正确的做法，当您通过时，某些数据库管理任务变得更容易数据量的某个断点。
答案 1 :(得分：2)
我永远不会为每家公司创建一个新的数据库。如果您需要模块化设计，可以使用表格和正确连接的主键和辅助键来创建。这是我了解database normalization的地方，我相信它会帮助你。
这是我将使用的方法。 SQL Article
答案 2 :(得分：1)
我必须同意你的同事。关系数据库旨在处理大量数据，您所谈论的数字（1000多家公司，每家公司多个用户，100多个订单/天）都在预期的范围内。单独的数据库意味着：
如果您的网站变得庞大，您最终可能需要跨多个服务器分发您的数据。 当它发生时处理它。出于性能原因开始这种方式听起来像是过早优化。
答案 3 :(得分：0)
我没有亲自处理过这种情况，但我认为如果你想做商业智能，你应该将数据汇总到一个离线数据库中，然后你可以运行你想要的任何分析。
此外，将它们保存在单独的数据库中可以更轻松地跨服务器进行分区（如果您有1000多个客户，则可能需要这样做），而无需采用混乱的复制技术。
答案 4 :(得分：0)
我前面有一个类似的问题，得出的结论是单个数据库的可管理性更强。现在，我们有多个数据库（大约10个），特别是当我们升级代码时，它已经变得很难管理。我们必须迁移每个数据库。
好处是数据被彻底隔离。由于我们数据的敏感性，这是一件好事，但它确实使得跟上它变得更加困难。
答案 5 :(得分：0)
单独的数据库方法比另一方面有很大的进步：
+你可以将它分成更小的组，这种架构可以更好地扩展
+您可以轻松地制作独立服务器。
答案 6 :(得分：0)
这取决于您的架构有多大可能发生变化。如果他们必须更改，您是否能够安全地对1000个单独的数据库进行更改？如果在您的设计中发现可伸缩性问题，您将如何为1000个数据库修复它？
答案 7 :(得分：0)
我们与大量客户一起运营SaaS（软件即服务）业务，并选择将所有客户保留在同一个数据库中。管理1000个独立的数据库是一个可操作的噩梦。
您必须非常勤奋地创建数据模型以及访问它们的业务对象/报告查询。您可能需要考虑的一种方法是在每个表中携带公司ID，并确保每个WHERE子句都包含当前登录用户的公司ID。如果您使用数据访问层，则可以在那里强制执行该条件。
随着您的成长，您仍然可以通过在每个物理服务器上放置公司组来进行垂直分区，例如：服务器A上的前100家公司，服务器B上的下100家公司。