SQL Server - 空列的性能/大小缺点

我正在研究一个表设计,它可能涉及大约10个字段中的许多NULL值,可能是75%的字段未被使用的时间.

我刚刚生成了一些假数据(一百万条记录),并且无法感知对SQL Server 2005的任何影响.大小差异在KB中.性能 - 在向3个不可为空的列添加索引后没有可测量的差异.

我知道SQL Server 2008具有稀疏列功能(我假设它将用于下一个SharePoint的UserData表).我希望我的代码可以在2005上运行.但是当前SharePoint UserData表的设计中存在大量NULL值.所以,如果它对微软足够好......

关于SQL Server表中许多NULL值的缺点或痛点的任何好文章,链接,白皮书？当你扩展到10 mil或100 mil记录时,任何人都有任何经验吗？

我从来没有遇到多个空列上的性能问题,即使是在100个演出规模的数据库上也是如此.我想如果你在这些字段上运行索引然后在查询中使用null,你最终会遇到问题,但我个人并没有将此视为问题.然后,我还没有创建数据库表,其中除3之外的每个字段都可以为空.

另一方面,当大多数数据为空时,我看到了一个架构问题.一般原因是:a)数据库规范化程度不正确或b)尝试允许用户在结束表中分段数据,而不是在提交数据库之前创建单独的表来"构建"数据.

由您决定数据库的最佳体系结构.

我在这种情况下做的很常见,就是把数据分成两个表:

所需数据

可选数据

例如,我目前正在编写一个社区网站,其中一个表显然是一个用户表.我正在记录有关用户的大量信息,因此我将收集的数据拆分为两个表:

用户

的UserDetails

该用户表中包含我需要所有的时间,如用户名,姓名和会话信息的基本信息.

该的UserDetails表含有我不需要经常如个人主页,邮箱地址,密码,网站地址,出生日期等额外信息.

这称为垂直分区.