因项目而已，纯属个人总结记录：
1、建立外键关系：通过外键关系，保持数据一致性及更新同步性。比如，目前数据库存在涉及到引用另一数据表的信息，直接在本表重复建数据库字段（或ID串），在查询时表面看来似乎减少了表连接所用的时效，但如此却很难保持数据统一，比如被引用数据发生改变时，引用起数据表中仍为原信息，且造成数据冗余。
2、涉及到表之间有关联关系的，应建立外键约束，以保持数据同步更新。如表1中用到表2中仅“名称”一个字段，也应建立外键关系，而非只是把表2中名称值放入表1，尽管这样sql少了一层关联，但效率提高效果上并不明显。
3、对于数据库设计文档要保存数据库物理模型图，只保存数据库中么个表的结构（字段）信息，很难高效掌握数据库表之间的逻辑关系，因而在实现业务时也很难直接得到执行的业务sql。
4、对于数据库访问层，常用的访问sql规范化，方法中固定了sql的结构及拼接方式，只需在方法参数中传入构成sql需要的参数，如此可以简化代码，而且可以使每个操作数据库人员执行的sql写法相同，也可以保证sql效率达到目前最优，日后一旦发现更好的sql，可以只修改方法中sql的拼接及定义方式。
5、对于数据访问层，不同的方法，涉及到对数据库做相同交互的要封装出一个公用的方法，以便维护。如将DataTable数据转换为Model方法、根据条件到数据库中查询DataTable数据集方法等，封装好后，其他方法只需调用封装好的方法，将数据做处理。
6、（参考）对于获取全部数据的情况，如查询数据表全部内容，获取数据实体Model等情况，业务上为查询数据表全部列，则可以使用select * 而不是select 字段1， 字段2...，因为当数据表增加字段时，第二种方式需要依次修改，不便维护。
7、适当使用存储过程，比如分页方法。也许存储过程（在数据库中建临时表）实现方案效率更高。
8、对于Model类中字段类型的定义，可均采用string类型，因为string类型很容易实现转换为其他类型，使用灵活。如此可以统一DAL层中add及update方法，拼接sql过程中，对每个字段判断是否为null，不为null才拼入sql中。均设为string的优点是，一些特殊类型，如整形为空，时间类型等等，通过字符串处理转换比较简单，但也有个缺点，就是在数据库访问层拼接sql时，要清楚哪个字段需要做如何的类型转换，比如时间类型，sqlserver中需要cast转换，oracle需要to_date，postgresql需要timestamp
'2001-02-16 20:38:40'。
9、对于存储大数据两数据表，或业务中普遍应用的查询条件，建立索引。
