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

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

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

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

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

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

谢谢！

更新：

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

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

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

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