|
锁定老帖子 主题：数据库的设计原则：关联还是不关联？
精华帖 (2) :: 良好帖 (0) :: 新手帖 (8) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-01-07
bizzad 写道 我们现在这个做了4年还在做，200m，50多万行的项目现在是倾向于完全不建关联了，新的数据模型一律不考虑关联 楼上能详细说说吗？ |
| 返回顶楼 | |
|
发表时间：2009-01-07
完全关联 完全不关联都不好
过犹不及 中庸才是正途 结论就是： 尽量关联 不关联是作为关联的特例 而不是常态 |
| 返回顶楼 | |
|
发表时间：2009-01-07
最后修改：2009-01-07
sdh5724 写道 看你做什么样一个压力的系统了， 如果的系统是每秒要上万个交易的话， 亲爱的， 我建议你少用join吧。少于１Ｗ／Ｓ的系统， 无所谓， 怎么搞都一样的。 完整性比任何都重要， 在压力过高的时候， 妥协而已！ 我的策略就是对于主压力的表， 一般来说， 系统中总是有几个焦点表的， 数据访问压力高， 读写密集的， 这个几个表好好设计， 不要关联，把读写操作让能力好的， 经验丰富的程序员去做封装ＤＡＯ ＡＰＩ。 其他的小表， 要做关联， 防止程序员出问题。
对于变态的性能需求. 与人类理解力的需求. 这对矛盾,有很大的分歧 对于理解方便来说,当然不关联好一些....因为大多数代码里已经有了关联.... 对于数据完整性来说,(安全性的一种)当然是放在数据里更好... 性能问题不考虑,. 所以说这个问题是指数据关联是放在代码里好还是放在数据里好的问题. 从开发角度来讲放代码里好开发 从维护角度来讲放数据里可以保护数据,可以把约束传递给下一个系统. 但从现实角度,往往性能问题才是最关键的......(因为建表的人一般都是DBA) |
| 返回顶楼 | |
|
发表时间：2009-01-07
打倒小日本 写道 完全关联 完全不关联都不好
过犹不及 中庸才是正途 结论就是： 尽量关联 不关联是作为关联的特例 而不是常态 特例？我倒觉得关联应该是特例 |
| 返回顶楼 | |
|
发表时间：2009-01-10
网站数据库设计 多采用反范式设计
除了开发的方便 也还考虑到访问量问题 个人倾向于少关联 |
| 返回顶楼 | |
|
发表时间：2009-02-18
现在做项目在设计时会考虑关联，特别是一些业务上关系紧密的数据
开发、测试时没有关联，等项目第一次完整测试后，再加上关联 |
| 返回顶楼 | |
|
发表时间：2009-02-18
楼上的说法 很令人费解 你测试不包含测关联性的吗 测试时没有关联性那你测试还有什么用？
|
| 返回顶楼 | |
|
发表时间：2009-02-18
sdh5724 写道 看你做什么样一个压力的系统了， 如果的系统是每秒要上万个交易的话， 亲爱的， 我建议你少用join吧。少于１Ｗ／Ｓ的系统， 无所谓， 怎么搞都一样的。 完整性比任何都重要， 在压力过高的时候， 妥协而已！ 我的策略就是对于主压力的表， 一般来说， 系统中总是有几个焦点表的， 数据访问压力高， 读写密集的， 这个几个表好好设计， 不要关联，把读写操作让能力好的， 经验丰富的程序员去做封装ＤＡＯ ＡＰＩ。 其他的小表， 要做关联， 防止程序员出问题。
每秒9000个交易的话，“无所谓， 怎么搞都一样的。”？ 牛 
我还停留在每秒几百个交易的阶段.. |
| 返回顶楼 | |
|
发表时间：2009-02-18
基本不考虑关联
|
| 返回顶楼 | |
|
发表时间：2009-02-22
具体问题具体分析了，就像表设计中打破范式一样，先范式设计表，再打破范式。不用关联将数据冗余到一张表中,在数据量大的时候自然要比关联的快,但占用的物理空间肯定要大些。
|
| 返回顶楼 | |
