我正在努力创建一个最好描述为CRM的应用程序。有一个相对复杂的表结构，我正在考虑允许用户进行相当多的自定义（添加字段等）。一个问题是我几乎会立即达到一定程度的规模。我们有大约50,000名个人用户将在推出后大约九个月内上线。所以我想建立持久。
我正在考虑两种甚至三种选择。
一个表设置了所有内容的userID列，并且通过创建索引自定义属性的表创建了自定义属性表，然后是另一个具有其值的表，然后可以将其连接到现有的联系人记录中用户。 - 从我所读到的，这似乎是正确的选择，但我一直觉得它不是。看起来，一旦这些表开始达到数百万条记录，只搜索每个查询中的一个用户记录将成为数据库的重量。
为每个用户帐户重新创建表集，并使用唯一标识符（例如userID）进行预设。然后，而不是使用WHERE userID =？我到处都可以使用FROM？_contacts。对于属性，我可以拥有一个自定义属性表，用户可以在其中为自定义属性添加其他列。 - 这感觉就像最简单的方法，当然，当我决定改变数据库结构时，会有一个从地狱迁移。
第三个选项，我非常有信心是错的，但仅仅因为这个原因，我不能排除，是应该为每个用户创建一个新的数据库，包含所有必需的表。
答案 0 :(得分：1)
第一种方法是最好的。创建 个人userId ，然后您可以为其分配特定角色。数据库检索时间确实也取决于记录的数量。但是，你可以在这里进行权衡，efficient sql queries to fetch data。好吧，根据这个site，您可能不会耗尽内存或遇到并发问题，因为如果您有效地编写查询，那么只要有良好的服务器，性能就应该很好。 / p>
如果重新创建表集，您最终将创建大量表，并且可能使索引变慢，这是一种不好的做法。然而，如果您选择关系数据库方案而不是普通的数据库方案，并且规范化数据库和数据表以提高效率。
为每个用户创建一个新数据库，只是总结了上述两个语句的复杂性，导致数据库访问破旧和混乱。因为，如果您决定为每个用户运行单独的数据库实例，您最终会消耗服务器物理资源，如RAM和CPU使用率，这将影响所有其他用户的服务质量。
选择选项1.分配单独的userIds并在需要时为其分配角色和权限。这比其他两种方法更有效。