数据库设计 – 数据库设计问题

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

此应用程序要求我为每个用户跟踪大量属性.这么多,我可能会用完列(行存储空间).

我很想添加一个UserProperties表,其中包含UserID,PropertyKey和PropertyValue列.这种方法非常符合要求.

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

我认为使用UserID上的聚簇索引,该访问仍然会快速尖叫,并且您实际上存储的数据量与使用mega-columns方法时的数据量相同.

关于性能问题的任何想法或想法？想要更好的数据库设计？

谢谢！

更新：

首先,非常感谢所有伟大的回应！

我一直在玩弄各种可能性,有一件事一直困扰着我.我需要经常查询其中一些属性,更糟糕的是,这些查询可能涉及同时查找多达10个这些属性的标准的所有用户.

因此,我现在倾向于采用巨型列方法,但可能将数据拆分为一个(或多个)单独的表,从而形成一个一对一的关系,该关系键在UserID上.

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

解决方法

E-A-V表易于搜索.问题是找不到行,它找到了相关的行.

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

我们可以轻松查找属性键,但没有任何组合这些属性键.

维基百科有一篇关于E-A-V的非常好的文章,但现在读它 – 它主要是一位作者的作品,并且是为了“改进”.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!