| 導購 | 订阅 | 在线投稿
分享
 
 
 

數據庫設計中經常用到的計算表寬度的腳本

來源:互聯網  2008-07-19 08:21:41  評論

在數據庫的設計過程中,我們經常會發現一些非常寬的表,雖然它們的出現使我們編碼工作方便了許多,但很多人都會擔心這樣的異常會不會對數據讀取和數據庫的整體性能有所影響。本文中,我們主要介紹了幾個計算表寬度的實例腳本,希望對大家的學習和工作有所幫助。

方法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符號整型數據或日期時間類型等等,那麽這樣的數據庫肯定是沒有經過缜密的考慮,在此情況下,這個設計團隊應當進一步的加強數據庫方面的學習。

在數據庫的設計過程中,我們經常會發現一些非常寬的表,雖然它們的出現使我們編碼工作方便了許多,但很多人都會擔心這樣的異常會不會對數據讀取和數據庫的整體性能有所影響。本文中,我們主要介紹了幾個計算表寬度的實例腳本,希望對大家的學習和工作有所幫助。 方法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符號整型數據或日期時間類型等等,那麽這樣的數據庫肯定是沒有經過缜密的考慮,在此情況下,這個設計團隊應當進一步的加強數據庫方面的學習。
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 熱帖排行
 
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有