对数据库模型进行性能优化

在一个数据库应用程序中，程序是从一个健全的数据库模型开始的。明白了这一点后，我们来看几种可以优化数据库模型的方法，通过这些方法可以提高查询效率。
(1) 少许的逆规范化(denormalization)大有帮助。尽量避免这样的数据库模型：它有一个名为Gender的表，表中有3个值。如果你有一个1:1关系的表，而且它经常被它的父表访问，那么你可以考虑合并这两张表。
(2) 让应用程序多承担一些责任。如果可以通过应用程序更容易地析取数据，为什么还要生成视图来强制数据以某种确定方式出现呢？
(3) 对数据进行水平分割。如果你有一个表示Web站点点击率的表，则可考虑把它按月份划分为12个表。如果数据是分布式的，那么你的负荷就变成了原有的1/12。这也可以让你把一些数据放在各个独立的服务器上，然后使用分布的划分视图来更新和查看数据。这样做使你可以对当前月份使用更加积极的索引策略，并且对已经过去的月份使用更高的填充度。
(4) 在行中保持尽可能少的内容。换句话说，不要使用一个char(255)类型来存储一个用户名的值，这只会造成空间的浪费。
(5) 为了不破坏引用的完整性，要避免使用触发器。使用外键约束要快得多，并且这种约束更适合处理大多数的操作。
(6) 避免使用text类型的字段。尝试找出对字段的确切要求是什么。如果你准备最多插入2000个字符，那么使用varchar(2000)会更加有效。
(7) 除非你要使用多种语言，否则不要使用像nvarchar和ntext这样的Unicode数据类型。然而要牢记，当你使用DTS从另一个数据源(如Access)转换数据的时候，DTS经常在服务器上创建Unicode的列。如果你的公司打算使用多语言，那么你就会需要这些数据类型。
(8) 避免在标识列上创建聚集索引。聚集索引对于范围查询执行起来更好，如一个日期。如果在标识列上存在聚集索引，你的数据就有收到“热点”的风险。注：“热点”是由于很多人更新同一数据页所引起的。
(9) 可能的话，就不允许列为NULLS。如果你知道你总是会得到地址信息的话，那么你就不需要为空的列。处理NULLS会增加额外的开销。
(10) 在某些情况下，如果表中存在惟一的数据列，那么要避免使用标识列。例如，如果用户名的值是惟一的，就不要另外创建没有必要的键。这样可以防止从子表中创建不必要的连接来确定用户名。这可能会占用一些存储空间，但可以给你节省大量的查询时间。要灵活处理这种实际情况，但如果行中已经存在惟一的值，那么为什么还要人工去给它分配一个呢？