我的问题与特定技术无关，而与应该选择的设计方法有关。我的公司即将创建一个 Web 应用程序，其用户将是公司公司。该应用程序将存储所有注册/注册公司的数据，包括财务数据。从数据库的角度来看，我们不确定应用程序的架构应该是什么。
我可以想到两种方法：
具有相同代码库的所有公司的单一数据库。使用公司表标识公司。
每个公司的单独数据库具有相同的代码库，或者每个公司/客户可能是不同的代码库。
这两种方法都有其优点和缺点。如果使用单个数据库，则数据大小将快速增加，并且由于多个公司用户访问同一数据库的负载可能会遇到性能问题。这种方法的好处是模式很容易管理模式。另一方面，单独的数据库具有降低性能开销和公司数据隐私的好处。但困难的部分是需要在所有公司数据库中复制模式中的单个更改。
这些是我们所知道的。作为我们政策的一部分，我们不会将代码出售给公司/客户。他们只会购买许可证。
我们只对关系数据库感兴趣，不会使用 NoSQL。此外，客户/公司的数量将不受限制，可以增长到任意数量。
设计这种场景的数据库架构的更好方法是什么。我知道有成千上万的应用程序在开发之前可能会遇到这种情况，但这是我第一次 :)
所以真的很想你就什么是更好的方法提供意见。
非常感谢！
让我从以下开始：您错过了 3：多个数据库，每个数据库都包含多个客户端的数据 - 既允许横向扩展（重要），也允许不拥有数十万个数据库。
但即便如此，你确实有一些糟糕的逻辑 - 基本上它比你想象的要少得多：
啊，是的，如果您有十几个数据库并且您的服务器太慢，则会发生完全相同的情况。除非您有很多只需要加载一次的共享数据，否则数据大小的增加也是相同的。
不。您处理的是产品，因此模式管理应该是完全自动化的。毕竟，无论如何，您可能必须管理一打或两个数据库副本的模式 - 开发，每个开发人员可能有一个单独的模式，一些用于测试，然后是质量控制。除非您计划一切手动发生，否则数据库更改将使用更改脚本并自动执行。
并且一旦自动化 - 管理 1000 个数据库副本就不再是一个问题了，或者？
不，我的意思是，是的，它的性能开销更少。但这是明智且无关紧要的 - 我怀疑开销超过百分之几。隐私可能很重要，它使很多场景更容易区分客户。但前提是您为每个客户（或良好的维护窗口）拥有单独的 Web 服务器 - 否则您必须在与代码完全相同的时刻更新所有数据库。玩得开心。
隐私可能很重要。它还允许轻松导入和导出数据。以及在出现错误时轻松地将数据传输到单独的实例，以便人们查看它。
它还可能会在 Web 服务器和数据库服务器上使用更多资源，因为连接管理将使用更多连接，因为它们不可重用。除非您部分围绕它进行编程。
只有当你的开发过程真的落后和 1990 年左右。敏捷和 DevOps 已经要求解决这个问题，所以这是一个长期解决的问题，无论如何你都有它。不确定你的团队是如何工作的，但我目前在一个项目中的一个小团队（大约 6 个开发人员）。一个生产数据库。数据库副本总数约为 20 - 多个测试环境，每个开发人员都有一个单独的数据库用于他的工作、质量控制、走廊测试，都有自己的数据库副本。因此，模式管理是完全自动化的。我不在乎有 1000 个其他副本来运行脚本。这是一个多一点的脚本（时间和并行性要求是一个问题），但核心问题无论如何都解决了。如果你没有这个，