我应该为 CRM 的多个用户创建多个表，甚至是数据库吗？答案

【问题标题】：Should I create multiple tables, or even databases for multiple users of a CRM我应该为 CRM 的多个用户创建多个表，甚至是数据库吗？
【发布时间】：2013-12-02 22:21:54
【问题描述】：

我正在创建一个最好描述为 CRM 的应用程序。有一个相对复杂的表结构，我正在考虑允许用户进行一些自定义（添加字段等）。一个担忧是我几乎会立即达到一定的规模。我们有大约 50,000 名个人用户，他们将在发布后的大约九个月内上线。所以我想建立持久。

我正在考虑两个甚至三个选项。

一个表集在所有内容上都有一个 userID 列，并具有一个自定义属性表，该表是通过创建一个索引自定义属性的表创建的，然后是另一个具有其值的表，然后可以将其连接到现有的联系人记录用户。 -- 从我读到的内容来看，这似乎是正确的选择，但我一直觉得它不是。似乎一旦这些表开始达到数百万条记录，在每个查询中只搜索一个用户记录，就会成为数据库中的大猪。
为每个用户帐户重新创建表集，并使用唯一标识符（例如 userID）进行修饰。然后，而不是使用 WHERE userID=?我可以在任何地方使用 FROM ?_contacts。对于属性，我可以有一个自定义属性表，用户可以在其中为自定义属性添加额外的列。 -- 这感觉像是最简单的方法，当然，当我决定更改数据库结构时，肯定会从地狱迁移。
第三个选项，我很有信心是错误的，但仅出于这个原因，我不能排除应该为每个用户创建一个包含所有必需表的新数据库。

我疯了吗？选项一真的是最好的吗？

【问题讨论】：

50,000 个用户。有多少家公司？
这个答案可能很有用 - stackoverflow.com/a/876459/1048425
@MikeSherrill'Catcall' 我讨厌人们都对他们的 IP 细节一无所知，但在这种情况下我不得不这样做。最终结果是，虽然应用程序在结构上类似于 CRM，但它不是一个，因此 50k 用户不会在他们的组织内共享数据。

标签： sql sql-server database

【解决方案1】：

第一种方法是最好的。创建个人 userId 的，然后您可以为他们分配特定的角色。数据库检索时间确实也取决于记录的数量。但是，有一个权衡，你可以写efficient sql queries to fetch data。好吧，根据这个site，您可能不会耗尽内存或遇到并发问题，因为使用好的服务器，性能应该很好，前提是您编写查询的效率很高。

如果您重新创建表集，您最终会创建大量表，并且会使索引速度变慢，这是一种不好的做法。而如果您选择关系型数据库方案而不是普通的数据库方案，并规范化数据库和数据表以提高效率。

为每个用户创建一个新数据库，只是总结了上述两个语句的复杂性，导致数据库访问破旧和杂乱无章。因为，如果您决定为每个用户运行单独的数据库实例，您最终只会消耗服务器的物理资源，例如 RAM 和 CPU 使用率，这将影响所有其他用户的服务质量。

选择选项 1。分配单独的 userId 并在需要时为其分配角色和权限。这比其他两种方法更有效。

【讨论】：