数据库设计中经常用到的计算表宽度的脚本

在数据库的设计过程中，我们经常会发现一些非常宽的表，虽然它们的出现使我们编码工作方便了许多，但很多人都会担心这样的异常会不会对数据读取和数据库的整体性能有所影响。本文中，我们主要介绍了几个计算表宽度的实例脚本，希望对大家的学习和工作有所帮助。

方法1： DBCC SHOWCONTIG

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

简单的 DBCC SHOWCONTIG 命令

以下是引用片段：

USE AdventureWorks;

GO

DBCC SHOWCONTIG WITH TABLERESULTS;

GO

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

方法2：- 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 语句

USE AdventureWorks;

GO

SELECT CAST(DB_NAME(DATABASE_ID) AS VARCHAR(20)) AS 'DatabaseName',

CAST(OBJECT_NAME([OBJECT_ID]) AS VARCHAR(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

FROM SYS.DM_DB_INDEX_PHYSICAL_STATS

(DB_ID('AdventureWorks'),NULL,NULL,NULL,'DETAILED');

GO

sys.dm_db_index_physical_stats – 带有ORDER BY从句的基本SELECT语句

USE AdventureWorks;

GO

SELECT CAST(DB_NAME(DATABASE_ID) AS VARCHAR(20)) AS 'DatabaseName',

CAST(OBJECT_NAME([OBJECT_ID]) AS VARCHAR(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

FROM SYS.DM_DB_INDEX_PHYSICAL_STATS

(DB_ID('AdventureWorks'),NULL,NULL,NULL,'DETAILED')

ORDER BY avg_record_size_in_bytes DESC;

GO

Database Design Considerations

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

究竟什么时候应该考虑评测你的数据库设计方案(宽的表)。具体的几个方面如下：

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

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

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

假如一个数据库包含一些很宽的表，所有的列都是文本数据类型，但是其中一些更适合使用integer符号整型数据或日期时间类型等等，那么这样的数据库肯定是没有经过缜密的考虑，在此情况下，这个设计团队应当进一步的加强数据库方面的学习。