首页 | 论坛 | 新闻资讯 | 设计欣赏 | 设计教程 | 网络编程 | 字体下载 | 平面教程 | 特色图标 | 设计素材 | 代码素材 | 网页模板 | 建站服务
卡通 | 环境 | 平面设计 | 网页设计 | 广告艺术 | 时尚摄影 | 形像设计 | 插画设计 | 三维设计 | 工业设计 | 时尚摄影 | 时尚时装 | 界面设计
·企业建站只需388元/年(可免费试用)
·制作大型专业网站,亦是如此简单
·文字广告位招租 ·文字广告位招租
·文字广告位招租 ·文字广告位招租
 当前位置:主页>网络编程>数据库教程>数据库技巧>列表
数据库设计中经常用到的计算表宽度的脚本
2008-07-22  来源:网络收集   作者:未知  点击:   评论:0 条
 

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

 

方法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符号整型数据或日期时间类型等等,那么这样的数据库肯定是没有经过缜密的考虑,在此情况下,这个设计团队应当进一步的加强数据库方面的学习。

[收藏]  [推荐]  [评论]  [打印]  [关闭]
上一篇:教你在 SQL Server 数据库中导入导出数据
下一篇:没有了
 最新图文
 最新评论
查看所有评论
评论内容:不能超过250字,需审核,请自觉遵守互联网相关政策法规。
用户名: (新注册) 密码:
匿名?
免责声明:本站刊载此文不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。对本文有异议,请联络本站! 转载要求:文章作者及来源信息必需保留。转载之图片、文件,链接请不要盗链到本站地址,且不准打上各自站点的水印。
 热门关注
 相关文章
 Google提供的广告