T-SQL脚本：计算表的宽度

　　问题

　　我担心我们的数据库设计有点过于异常。我发现我们常常会有一些非常宽的表，虽然这样使我们编码工作更加方便，但是我很担心这样的异常会不会对数据读取和数据库的整体性能有所影响。在我修改这些表或者改变我们的团队以后的数据库设计方法之前，我想知道怎么才能知道，相对于理论上的最大宽度，这些表的实际宽度是多少?你可不可以提供一两个脚本，让我可以在我的SQL Server数据库里运行?还有没有什么数据库设计实例的资料可以提供?我知道数据库设计有一点异常现象是正常的，我只是不知道我的数据库设计是不是有点过于异常。

　　回答

　　说到计算表的宽度，倒是有一些不同的方法可供选择。先看看下面几种方法的脚本。至于数据库设计方面，我们再后文另外讨论。

　　方法一： DBCC SHOWCONTIG

　　DBCC SHOWCONTIG命令可以报告与行相关的信息，可以考虑使用它来计算表宽。这是通过使用WITH TABLERESULTS选项来完成。然后根据你的需要可以检查以下几项： MinimumRecordSize、 MaximumRecordSize和 AverageRecordSize。

　　简单的 DBCC SHOWCONTIG 命令

以下是引用片段：
　　USEAdventureWorks;
　　GO
　　DBCCSHOWCONTIGWITHTABLERESULTS;
　　GO

　　要谨记的一点是，DBCC SHOWCONTIG的这个功能只在SQL Server 2000和SQL Server 2005里有。不建议繁忙的SQL Server数据库在工作时间运行这个命令，可以在非工作时间或着维护窗口或数据库备份里运行该命令。

　　方法二：- sys.dm_db_index_physical_stats

　　SQL Server 2005的一个新特性就是更加生动的管理视图和函数。在这种情况下我们可以方便使用的就是sys.dm_db_index_physical_stats。管理视图和函数最大的优点在于可以通过非常简单的SELECT语句进行查询。下面是几个使用AdventureWorks SQL Server 2005数据库的例子：

以下是引用片段：
　　sys.dm_db_index_physical_stats–基本的SELECT语句
　　USEAdventureWorks;
　　GO
　　SELECTCAST(DB_NAME(DATABASE_ID)ASVARCHAR(20))AS'DatabaseName',
　　CAST(OBJECT_NAME([OBJECT_ID])ASVARCHAR(20))AS'TableName',
　　index_id,
　　index_type_desc,
　　alloc_unit_type_desc,
　　min_record_size_in_bytes,
　　max_record_size_in_bytes,
　　avg_record_size_in_bytes
　　FROMSYS.DM_DB_INDEX_PHYSICAL_STATS(DB_ID('AdventureWorks'),NULL,NULL,NULL,'DETAILED');
　　GO
　　sys.dm_db_index_physical_stats–带有ORDERBY从句的基本SELECT语句
　　USEAdventureWorks;
　　GO
　　SELECTCAST(DB_NAME(DATABASE_ID)ASVARCHAR(20))AS'DatabaseName',
　　CAST(OBJECT_NAME([OBJECT_ID])ASVARCHAR(20))AS'TableName',
　　index_id,
　　index_type_desc,
　　alloc_unit_type_desc,
　　min_record_size_in_bytes,
　　max_record_size_in_bytes,
　　avg_record_size_in_bytes
　　FROMSYS.DM_DB_INDEX_PHYSICAL_STATS(DB_ID('AdventureWorks'),NULL,NULL,NULL,'DETAILED')
　　ORDERBYavg_record_size_in_bytesDESC;
　　GO
　　DatabaseDesignConsiderations

　　数据库设计需要考虑的问题：

　　到底什么时候应该考虑评测你的数据库设计方案(宽的表)，以下是几个方面：

　　好或不好——考虑到表的使用，宽的表不一定是不好的设计方案。对于需要生成报表的工作环境，一些数据库会设计地比较宽，来满足报表需要，这样可以生成简单的界面。

　　消除多表连接——在OLTP环境里，有些情况下会通过重复数据来消除多表连接。根据不同的情况以及重复数据的维护，这可能是保证良好的用户体验的一个重要技术。

　　重复列——我觉得这种情况是很典型的标志，说明要么是数据库设计不够严谨，要么就是数据库已经开发了很长时间了。如果一个表有三列以上意思一样的列，比如产品一，产品二，产品三，那么可以说是一个很典型的一对多关系。另外需要考虑的一点是，如果订单里还有第四个产品或第五个产品，那怎么办呢?

　　如果一个数据库包含一些很宽的表，所有的列都是文本数据类型，但是其中一些更适合使用integer符号整型数据或日期时间类型等等，那么这样的数据库肯定是没有考虑周密，或者设计团队根本还需要进一步加强数据库方面的学习。