【賽迪網－IT技術報道】在數據庫的設計過程中，我們經常會發現一些非常寬的表，雖然它們的出現使我們編碼工作方便了許多，但很多人都會擔心這樣的異常會不會對數據讀取和數據庫的整體性能有所影響。本文中，我們主要介紹了幾個計算表寬度的實例腳本，希望對大家的學習和工作有所幫助。
方法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符號整型數據或日期時間類型等等，那麼這樣的數據庫肯定是沒有經過縝密的考慮，在此情況下，這個設計團隊應當進一步的加強數據庫方面的學習。（責任編輯：盧兆林）
