数据库设计三板斧

简单粗暴点,但效果比较明显.扔出来引玉. 1、根据业务需求，按照范式设计常规化的数据库结构 2、把报表一张张的过，审验现在的表结构是否可以满足统计报表容易的出。不容易出的，自行设计额外的表、视图、自定义函数 3、把功能中的查询Grid列表、查询条件拿出来一张张的过，审验现在的表结构是否可以满足查询容易的出。不容易出的，自行设计额外的表、视图、自定义函数 很多人不知道在设计期如何加索引,在什么字段上加索引,是加聚集索引还是非聚集索引.我个人的经验是: A、主键一般是聚集索引，但聚集索引是要求最好是有序的，因为聚集索引要决定物理记录存放，所以咱们的GUID主键字段最好变成有序GUID。SQLSERVER2005专门有方法可以使GUID有序。 B、看数据库E-R图，表之间的外键关系（可能你并没有建立真正数据库外键，但事实上存在外键关系），把最频繁使用的那几张核心业务数据表之间的外键关系建立好非聚集索引。这是JOIN关联经常用的。 C、把查询和报表都过一遍,把查询参数和报表参数审视一下,这是经常要做的查询条件。根据主键和查询条件，综合得出非聚集索引的选择。 经过这三招选择的索引，它不会是在客户生产环境下最优的索引，但它也是中等偏上的水平，这样就可以让没有索引优化经验的人也可以有方法的设计出有一定水准的数据库表结构和索引。 经过三板斧，这个数据库设计就比较满足查询、增删改、统计报表的需求了。 如果还怕数据表设计有闪失，那就额外送你一斧，那就是： 4、对于单据操作的，是否要留下过程字段信息变更记录。这样你在回溯数据、统计某个历史时间阶段的数据就非常容易。 如果你还不放心，那么再送你一斧子，那就是： 5、从业务功能的操作频繁程度，操作用户量，数据增长速度来估算一张表一年、3年、5年的数据增长量，通过估算的数据规模来再一次设计冗余表、历史数据表。 其他什么有序GUID索引、聚集索引选择、默认值与不可为空约束、关键核心表使用外键保证数据完整性，都是后话。 有时候，解决大部分问题，只需要简单几下。不信，你试试看。人说书生百无一用，很多时候就是叫真半天研究半天，得出来的结论和老百姓的常识是一样一样的。