27,579
社区成员
发帖
与我相关
我的任务
分享数据库设计规范讨论二之表设计
1.关于主键
1)从效率角度看，整数类型的主键应该比定长或变长类型的字符主键效率高，哪位有测试过效率一般会高多少？
2)通常来讲是否我们一般应该选择代理主键，比如自增值、GUID等？
3)如果使用用户自定义编码作为主键有什么不好？
4)如果是复合主键，比如有4个以上的字段组成主键，我们是否应该考虑用单一主键来代替，比如GUID？或者考虑反范式？
2.关于冗余
1)比如有一个订单，我们考虑一个订单有一个产品系列，这个系列的产品有很多规格，每个规格有自己的单价，我们要看这个订单包含多少规格，
包含多少产品数量，订单包含多少金额，我们是否应该把这些值包含在主表中？如果不包含，计算的效率估计会差多少？如果要包含，我们可以
通过哪些手段来保证数据的一致性？
2)在考虑冗余设计时，我们一般需要考虑哪些因素？
3.关于参照完整性
1)比如客户表，许多业务都会用到，一般我们是否应该把这些表全部和客户表关联？这样对查询和更新效率分别有多大的影响？
看过MS CRM的设计，几乎所有的表都和用户表作了关联？
2)我们是否应该选择级联更新或删除？
哈哈，欢迎大家发表高见，分不够再开帖。
1)从效率角度看，整数类型的主键应该比定长或变长类型的字符主键效率高，哪位有测试过效率一般会高多少？
2)通常来讲是否我们一般应该选择代理主键，比如自增值、GUID等？
3)如果使用用户自定义编码作为主键有什么不好？
4)如果是复合主键，比如有4个以上的字段组成主键，我们是否应该考虑用单一主键来代替，比如GUID？或者考虑反范式？
2.关于冗余
1)比如有一个订单，我们考虑一个订单有一个产品系列，这个系列的产品有很多规格，每个规格有自己的单价，我们要看这个订单包含多少规格，
包含多少产品数量，订单包含多少金额，我们是否应该把这些值包含在主表中？如果不包含，计算的效率估计会差多少？如果要包含，我们可以
通过哪些手段来保证数据的一致性？
2)在考虑冗余设计时，我们一般需要考虑哪些因素？
3.关于参照完整性
1)比如客户表，许多业务都会用到，一般我们是否应该把这些表全部和客户表关联？这样对查询和更新效率分别有多大的影响？
看过MS CRM的设计，几乎所有的表都和用户表作了关联？
2)我们是否应该选择级联更新或删除？
哈哈，欢迎大家发表高见，分不够再开帖。
...全文
请发表友善的回复…
发表回复
OracleRoob 2007-06-14
- 打赏
- 举报
听听
chump 2007-06-14
- 打赏
- 举报
期待您的建议.
最后一只恐龙 2007-06-10
- 打赏
- 举报
个人仅对Yang_(扬帆破浪) 说的级联问题有不同看法，其他说的很有道理。
外键是保证数据库完整性的手段之一，当更新或删除主键时，相应外键有三种可选择的操作：拒绝访问、级联操作或置空，个人认为级联有些情况比较危险，如部门下有很多用户，删除部门级联删除用户，可能很多用户信息是有用的，不小心删除部门会造成用户信息丢失。
但很多情况下还是有用的，如删除一个订单，级联删除订单的详细信息等。
外键是保证数据库完整性的手段之一，当更新或删除主键时，相应外键有三种可选择的操作：拒绝访问、级联操作或置空，个人认为级联有些情况比较危险，如部门下有很多用户，删除部门级联删除用户，可能很多用户信息是有用的，不小心删除部门会造成用户信息丢失。
但很多情况下还是有用的，如删除一个订单，级联删除订单的详细信息等。
xiaoku 2007-06-10
- 打赏
- 举报
学习...了
Andy__Huang 2007-06-10
- 打赏
- 举报
1)从效率角度看，整数类型的主键应该比定长或变长类型的字符主键效率高，哪位有测试过效率一般会高多少？
沒有測試過，但我覺得和產品的代碼特征有關係，的有需要特征代碼長一些，但有的並不需要，所以統一長度不見得有什麼好處？
2)通常来讲是否我们一般应该选择代理主键，比如自增值、GUID等？
可以這樣考慮，看對編程有什麼好處而決定
3)如果使用用户自定义编码作为主键有什么不好？
用戶不了解規則，
4)如果是复合主键，比如有4个以上的字段组成主键，我们是否应该考虑用单一主键来代替，比如GUID？或者考虑反范式？
我在編程中也用過4個復合主鍵，我覺得這是因為設計系統的需要，對程序歸類，系統查詢會有很大幫助
沒有測試過，但我覺得和產品的代碼特征有關係，的有需要特征代碼長一些，但有的並不需要，所以統一長度不見得有什麼好處？
2)通常来讲是否我们一般应该选择代理主键，比如自增值、GUID等？
可以這樣考慮，看對編程有什麼好處而決定
3)如果使用用户自定义编码作为主键有什么不好？
用戶不了解規則，
4)如果是复合主键，比如有4个以上的字段组成主键，我们是否应该考虑用单一主键来代替，比如GUID？或者考虑反范式？
我在編程中也用過4個復合主鍵，我覺得這是因為設計系統的需要，對程序歸類，系統查詢會有很大幫助
zhj92lxs 2007-06-10
- 打赏
- 举报
学习
Tayloryang11 2007-06-09
- 打赏
- 举报
麻烦Yang_(扬帆破浪)讲解一下为什么级联更新或删除是鸡肋
谢谢了
谢谢了
userqin 2007-06-09
- 打赏
- 举报
学习学习
wgzaaa 2007-06-09
- 打赏
- 举报
ding
hb_gx 2007-06-08
- 打赏
- 举报
我只是来学习学习
不是很懂，没资格发表意见
不是很懂，没资格发表意见
Yang_ 2007-06-08
- 打赏
- 举报
鸡肋 就是看起来很巧妙，实际不敢大用的功能，比如函数、级联、远程连接自己等等
w75251455 2007-06-08
- 打赏
- 举报
实习记者提个要求~~~说普通话。。。
滴泪中。。。。
滴泪中。。。。
w75251455 2007-06-08
- 打赏
- 举报
笔记中。。。
w75251455 2007-06-08
- 打赏
- 举报
鸡肋是啥意思。。。。
Yang_ 2007-06-08
- 打赏
- 举报
1.关于主键
1)从效率角度看，整数类型的主键应该比定长或变长类型的字符主键效率高，哪位有测试过效率一般会高多少？
与效率问题更挂钩的是聚集索引。
2)通常来讲是否我们一般应该选择代理主键，比如自增值、GUID等？
还是尽量少用的好
3)如果使用用户自定义编码作为主键有什么不好？
唯一的就怕用户修改编码规则，会死人的
4)如果是复合主键，比如有4个以上的字段组成主键，我们是否应该考虑用单一主键来代替，比如GUID？或者考虑反范式？
4个以上的字段应该代替
反范式？
2.关于冗余
1)比如有一个订单，我们考虑一个订单有一个产品系列，这个系列的产品有很多规格，每个规格有自己的单价，我们要看这个订单包含多少规格，
包含多少产品数量，订单包含多少金额，我们是否应该把这些值包含在主表中？如果不包含，计算的效率估计会差多少？如果要包含，我们可以通过哪些手段来保证数据的一致性？
这个例子肯定是要设计成主从表，好的索引能提高效率。
2)在考虑冗余设计时，我们一般需要考虑哪些因素？
冗余设计首先要考虑的是一致性，其次是大数据量情况下因为表太宽对效率的反作用。
3.关于参照完整性
1)比如客户表，许多业务都会用到，一般我们是否应该把这些表全部和客户表关联？这样对查询和更新效率分别有多大的影响？
看过MS CRM的设计，几乎所有的表都和用户表作了关联？
应该适当减少些关联，但是要保证一致性，至少在系统设计的配合下保证一致性。
2)我们是否应该选择级联更新或删除？
个人认为级联更新或删除是鸡肋
1)从效率角度看，整数类型的主键应该比定长或变长类型的字符主键效率高，哪位有测试过效率一般会高多少？
与效率问题更挂钩的是聚集索引。
2)通常来讲是否我们一般应该选择代理主键，比如自增值、GUID等？
还是尽量少用的好
3)如果使用用户自定义编码作为主键有什么不好？
唯一的就怕用户修改编码规则，会死人的
4)如果是复合主键，比如有4个以上的字段组成主键，我们是否应该考虑用单一主键来代替，比如GUID？或者考虑反范式？
4个以上的字段应该代替
反范式？
2.关于冗余
1)比如有一个订单，我们考虑一个订单有一个产品系列，这个系列的产品有很多规格，每个规格有自己的单价，我们要看这个订单包含多少规格，
包含多少产品数量，订单包含多少金额，我们是否应该把这些值包含在主表中？如果不包含，计算的效率估计会差多少？如果要包含，我们可以通过哪些手段来保证数据的一致性？
这个例子肯定是要设计成主从表，好的索引能提高效率。
2)在考虑冗余设计时，我们一般需要考虑哪些因素？
冗余设计首先要考虑的是一致性，其次是大数据量情况下因为表太宽对效率的反作用。
3.关于参照完整性
1)比如客户表，许多业务都会用到，一般我们是否应该把这些表全部和客户表关联？这样对查询和更新效率分别有多大的影响？
看过MS CRM的设计，几乎所有的表都和用户表作了关联？
应该适当减少些关联，但是要保证一致性，至少在系统设计的配合下保证一致性。
2)我们是否应该选择级联更新或删除？
个人认为级联更新或删除是鸡肋
leo_lesley 2007-06-08
- 打赏
- 举报
顺便站个楼层
leo_lesley 2007-06-08
- 打赏
- 举报
听听课
w75251455 2007-06-08
- 打赏
- 举报
偶是~实习记者
肥胖的柠檬 2007-06-08
- 打赏
- 举报
顶回上去
budong0000 2007-06-08
- 打赏
- 举报
mark
加载更多回复（9）
