DB 设计：为所有客户提供一个大型 DB 或多个小型 DB答案

【问题标题】：DB design: one large DB for all customers or many small DBsDB 设计：为所有客户提供一个大型 DB 或多个小型 DB
【发布时间】：2010-07-14 11:10:02
【问题描述】：

寻找任何建议或建议，甚至最佳做法。我已经使用 php 和 mysql 开发了一个在线数据库。它允许公司记录投诉和解决方案等。有一个用于登录的用户数据库和一个用于记录主要数据的 cip 数据库。 2 家公司正在试用和测试数据库。目前，每家公司都在使用单独的数据库和单独的 html 页面。我想知道添加更多公司的最佳方法是什么。
我的想法是：

1。拥有一个用于用户的大型数据库和一个用于 cip 的大型数据库，并使用公司 ID 或类似名称来识别数据库中的各个公司记录。

2。为每家公司使用相同的 html 页面，但从登录详细信息中选择要使用的数据库。这样每个公司都会有一个单独的 cip 数据库，但所有公司都使用相同的用户数据库。

3。或者只是将每家公司的所有内容分开。（这对于更新来说可能真的很糟糕）

我希望我已经说清楚了，并期待任何建议。

谢谢

【问题讨论】：

可能值得将此问题的标题更改为更具体的内容，例如“数据库设计：为所有客户提供一个大型数据库或许多小型数据库”。我还不能编辑问题，但是比我有更多声誉的人可以这样。
另见：stackoverflow.com/questions/2766334/…
我不反对有人将问题名称更改为“数据库设计：为所有客户提供一个大型数据库或多个小型数据库。”

标签： php mysql database database-design relational-database

【解决方案1】：

我想回答的一个问题是，您是否需要查看跨客户的数据以供您自己报告或使用？在这种情况下，您需要选择第一名，否则您将做噩梦以获得良好的报告。

您会根据客户进行任何定制吗？这表明将事物分开可能是更好的选择。如果你永远不会定制，那就不要分开。

我在所有这些选项中都使用过系统，而第一个是迄今为止最好的长期维护。但是，如果您有条理并计划好，所有这些都是可行的。如果您选择单独的选项，您必须能够将更改推送到所有客户端，因此必须通过保存在源代码控制中的脚本对数据库进行更改。您甚至可能需要按数据库版本保留源代码控制，以便客户端可以选择升级或不升级。当然，在选项 1 中，没有人可以选择继续使用旧版本。如果这更符合您的业务需求，那是选项 1 的加分项。

我非常同意 Ollie Jones 的观点，如果您使用选项一，您必须有良好的数据库安全设计，以防止客户端看到其他客户端的数据。我们曾经将一个客户端从一个只有客户端的服务器移动到一个共享数据库，只有一个 proc 错过了请求 client_ID（在旧系统中不需要它并且开发人员已经变得草率）最终通过电子邮件发送了所有所有其他客户的销售代表以及有关第一个客户的信息。这花费了公司很多钱（既要解决问题，又要发送电子邮件道歉，结果我们几乎失去了一个客户，不得不给他们一些成本减免以保留他们）和许多卑躬屈膝的道歉和开发商只是勉强错过了失去工作。让这成为你不费吹灰之力就能学到的一课。

【讨论】：

【解决方案2】：

我个人会选择候选人#3。除了用户部分，这些类型的数据库可以快速增长。为了最大限度地保持性能，建议您将表尽可能小。根据用户的凭据选择不同的数据库应该不难，因此应用程序逻辑不应该受到影响。

我理解您对可维护性的担忧。每个客户是否都使用完全相同的应用程序堆栈，或者他们是否有单独的安装？不管怎样，维护应该很容易编写脚本来执行多数据库更新。这不应该阻碍您选择这样的设计。

【讨论】：

【解决方案3】：

这是一个有趣的案例，说明您的便利性与保护客户数据安全的责任之间存在冲突。为了您的方便，很明显，多租户应用程序（如您的选项 (1) 中所述）将是最容易开始工作的。

但是，如果您的业务取得成功，您就会给自己带来未来的重大问题。按照您描述应用程序的方式，您的客户公司从来没有合法需要查看属于另一家公司的数据。事实上，如果他们看到彼此的数据，您将面临严重的安全漏洞需要处理。如果违规涉及个人记录，您将面临危及业务的成本和处罚。

因此，如果您确实选择了选项 (1)，请不要缩短您的代码检查和安全测试。如果您进行糟糕的安全测试，您会感到抱歉，更糟糕的是，您的客户也会如此。

为了更好的安全性，您可能需要考虑组合选项 (2) 和 (3)：单个 Web 应用程序代码库，将您的多租户位置从 Web 应用程序移动到 mySQL 服务器。 mySQL 安全系统非常擅长多租户：Wordpress、Drupal 和 Joomla 都以这种方式工作，并且都被广泛部署。

这种方法还有另一个优点。如果您进行必要的开发工作，为您的网络应用程序和数据库构建简单的安装脚本，您就可以将您的应用程序提供给客户，让他们在他们自己的服务器上运行（如果他们想要的话）。

我并不是说完全避免 (1)。您的企业可能会提供托管多租户应用程序（选项 1）解决方案，其服务条款可涵盖您的风险。而且，对于更大或更装备精良的客户，您可以提供私人解决方案。

【讨论】：

【解决方案4】：

如果您有 1 个名为 companies 的表，那么每个用户都可以有一个 company_id，因此它与该公司相关。您只需要 1 个数据库，只需使用一对多关系即可。

【讨论】：

【解决方案5】：

1 号是最好的方法。为您需要的所有信息建立一个数据库，并使用 ID 来识别公司。如果您不想修改当前的应用程序文件，您可以使用此 DB 布局，但创建视图，以模拟您的旧数据库结构。

【讨论】：

【解决方案6】：

拥有一个用于用户的大型数据库和一个用于 cip 的大型数据库，并使用公司 ID 或类似名称来识别数据库中的各个公司记录。

这是最好的选择。您可以将所有信息存储在一个数据库中，并根据用户登录来区分它们（您可以在其中知道用户是哪个公司并在会话中存储公司 ID）。但是，小心您的编码，因为错误可能会向公司显示其他公司拥有的一些信息。

【讨论】：

【解决方案7】：

只需一个供用户和公司使用的数据库即可。而且我认为您的页面中需要一些 php、asp 或 jsp 来识别用户并查询数据库...

【讨论】：

【解决方案8】：

第一点

为用户提供一个大型数据库和一个大型数据库，用于 cip 和使用公司 ID 或类似的识别个别公司的记录在数据库中。

我的意见是好的。因为数据库是为存储和管理大数据而构建和调整的。但唯一的想法是你应该正确设计桌子。避免数据重复等情况。构建和管理大数据集很好。但应该专注于设计。你应该调整你的表。为此，您可以在 google 上搜索数据库设计和性能调整。

为每个页面使用相同的 html 页面公司，但选择要使用的数据库从登录详细信息中使用。以便每家公司都有单独的 cip 数据库，但所有公司都使用相同的用户数据库。

最好是为所有公司建立一个基本模板。这将有助于管理您的应用程序。登录时，您选择公司需要或拥有的适当详细信息并将其加载到模板中。为公司创建一个登录表，从他们使用 id 点到您的信息数据集并将其加载到模板。这将帮助您进行调试，它是制作应用程序的标准方法。

喜欢脸书。每个人在登录时都有共同的主页模板，他们填写了他们的相关数据，如图片、视频、帖子等......

尝试开发这样的应用。

这些是我的建议..

【讨论】：

【解决方案9】：

我会选择解决方案 (1)，或者如果您认为您将有成千上万的客户使用您的网络应用程序 (2)。

(3) 绝对是一场噩梦。

顺便说一句，我想在解决方案 (1) 中，您也认为在解决方案 (2) 中使用相同的 html 页面，无论您是在大型数据库还是许多小型数据库上使用，我强烈建议您使用相同的应用程序逻辑（html/php 页面）始终适用于所有人。

【讨论】：

【解决方案10】：

您会发现仅使用单个数据库会容易得多。你在正确的轨道上，考虑维护成本等。

使用适当设计/相关的表格——例如：

Company Information Table
--------
Company_ID (primary key)
Company_Name
Other Fields...


Issue Table
--------
Issue_ID (primary key)
Company_ID (foreign key tied to the Company Information Table)
Issue_Text
Other Fields...

希望有帮助

【讨论】：