数据库设计规范讨论总结1

1.命名
1)许多建议以t或tb开头，为什么区分这个，难道是要区分嵌在代码中的sql语句中操作的对象是表还是视图？
答：表则不需要，多此一举；比如区分视图则使用v等；
2)是否要区分模块类型，比如系统、客户、合同，如命名为t_sm_***,t_cm_***等？
答：可以区分模块，但建议不要使用下画线；
3)是否区分表的种类，比如有人把表分为业务表、基本表、辅助表等，不知作用何在？
答：满足范式是必要的，区分表的种类是多余的；
4)是否使用下横线连接，比如t_a_ContType，好象这样书写比较困难些？
答：非常不好的习惯；
5)表名是否加s,比如Customers，好象MS老大就是这样命名哦。
答：完全没必要，如果有个表设计仅保存一条数据，则使用单数吗？
6)是否使用缩写？更有甚者使用table1\table2等命名的方式？保密吗？
答：使用有意义的单词而不是缩写，避免使用汉语拼音缩写。
2.设计
1)一般是否需要有建立时间、建立者、修改时间、修改者这几个字段？有人认为这样对数据库空间的消耗比较大.
答：一般建议使用，既可防抵赖，也可以实现数据级别的安全，比如只能建立者修改等；
2)关于字段类型，哈哈有人建议只使用字符类型，如日期使用char(19)替代？
答：哈哈，还是使用强类型的数据类型好啊，除非你要求在N种类型的数据库上运行而使用相同的脚本.
3)表中是否有必要设计时间戳字段？
答：笔者认为是处理并发的需要；
4)如果使用用户编码作为主键有什么不好？
答：如果用户编码的稳定性差，还是不要以其作为主键的好；
5)什么情况下使用代理主键，比如自增值比较好？
答：不建议使用自增作为主键，数据移植性差。使用代理键，一般如数据仓库中数据合并时，或则用户编码比较不稳定；
6)比如有合同表，有合同类型、业务员、销售部门、币种，后者什么情况下应该建立独立的表，否则是否在合同表中直接保存合同类型等即可？
答：考虑规范需要，一般还是使用代码表比较好；
3.关于主键
1)从效率角度看，整数类型的主键应该比定长或变长类型的字符主键效率高，哪位有测试过效率一般会高多少？
答：没有结论。
2)通常来讲是否我们一般应该选择代理主键，比如自增值、GUID等？
答：见2-5）。
3)如果使用用户自定义编码作为主键有什么不好？
答：见2-4）。
4)如果是复合主键，比如有4个以上的字段组成主键，我们是否应该考虑用单一主键来代替，比如GUID？或者考虑反范式？
答：这种情况建议使用单一主键。
4.关于冗余
1)比如有一个订单，我们考虑一个订单有一个产品系列，这个系列的产品有很多规格，每个规格有自己的单价，我们要看这个订单包含多少规格，
包含多少产品数量，订单包含多少金额，我们是否应该把这些值包含在主表中？如果不包含，计算的效率估计会差多少？如果要包含，我们可以
通过哪些手段来保证数据的一致性？
答：笔者认为应该尽量满足范式，因为对于一般的系统并不会对效率有多大的影响，除非数据量非常大。保证数据一致性除参照完整性外，
笔者认为触发器是一种很好的手段。
2)在考虑冗余设计时，我们一般需要考虑哪些因素？
答：没有结论。
3.关于参照完整性
1)比如客户表，许多业务都会用到，一般我们是否应该把这些表全部和客户表关联？这样对查询和更新效率分别有多大的影响？
看过MS CRM的设计，几乎所有的表都和用户表作了关联？
答：适当减少关联，但应尽量使用数据库的机制来保证数据的完整性而不是自己编程来控制。对插入和更新的效率有一定的影响，但不是关键因素。
2)我们是否应该选择级联更新或删除？
答：适当使用。