database-design - 数据库设计 : track a vast number of attributes for each user. 如此之多，我可能会用完列(行存储空间)

Question

对于我所关心的问题，我希望得到一些意见。

我的数据库中有一个 [User] 表，其中包含您期望的基本内容，例如用户名、密码等...

此应用程序要求我跟踪每个用户的大量属性。如此之多，我可能会用完列(行存储空间)。

我很想添加一个包含 UserID、PropertyKey 和 PropertyValue 列的 UserProperties 表。这种方法非常符合要求。

我担心的是，如果每个用户有 100 个属性，那么当数据库中有 100 万个用户时，我们将拥有 100,000,000 个属性行。

我认为，使用 UserID 上的聚集索引，访问速度仍然会很快，而且您实际上存储的数据量与使用大型列方法存储的数据量大致相同。

关于性能问题有什么想法或想法吗？有更好的数据库设计的想法吗？

更新:

我一直在考虑各种可能性，但有一件事一直困扰着我。我需要经常查询其中一些属性，更糟糕的是，这些查询可能涉及同时查找符合多达 10 个属性条件的所有用户。

因此，我现在倾向于采用巨型列方法，但可能会将数据拆分到一个(或多个)单独的表中，形成以 UserID 为键的一对一关系。

我正在使用 LinqToSql，虽然我认为具有这么多列的表格不太优雅，但我认为考虑到所有挑战和权衡，它可能是正确的，但我仍然渴望听到其他意见。

Answer 1

您所描述的是一个实体属性值数据库，它通常用于您所描述的情况，稀疏数据绑定(bind)到单个实体。

E-A-V 表易于搜索。问题不在于查找行，而在于查找相关行。

为不同的实体提供不同的表可以提供域建模，但它们也提供了弱形式的元数据。在 E-A-V 中没有这样的抽象。 (Java 与 E-A-V 的类比是声明所有函数的形式参数都是 Object 类型——因此您不会进行类型检查。)

我们可以轻松查找属性键，但没有任何东西可以对这些属性键进行分组。

维基百科有一篇关于 E-A-V 的非常好的文章，但现在就阅读它 - 它主要是一位作者的作品，并且预计会进行“改进”。