代码改变世界

数据库的设计原则：关联还是不关联？（转载）

2010-11-27 17:36  Dirichlet  阅读(503)  评论(0)  编辑  收藏  举报

转自：http://www.javaeye.com/topic/294903

数据库的设计原则：关联还是不关联？ 

 

设计网站数据库（确定使用Hibernate）的过程中，时常会有争论，争论的焦点主要还是集中在表与表之间的关联上面： 
有的倾向于去掉表与表之间的任何关联；有的拿完整性说话，必须保留所有的关联性。 


先说我的观点：我倾向于去掉所有的关联，为了开发的方便。然后写代码的时候自己留意完整性的问题。
返回顶楼
     
 
  • czx566
  • 等级: 初级会员
  • 性别: 
  • 文章: 148
  • 积分: 30
  • 来自: 未来
   发表时间：2008-12-16  
具体情况具体分析 

 

业务表 我认为关联要好 


而有一些历史信息比如日志什么的，我基本都不关联，而且最大冗余~
返回顶楼
     回帖地址
0  请登录后投票
 
  • xuyao
  • 等级: 初级会员
  • 性别: 
  • 文章: 256
  • 积分: 70
  • 来自: 北京
   发表时间：2008-12-16  
如果是DBA，一定建议你关联，因为数据需要是完整的。如果都不关联，开发是方便了，可是数据就不能保证正确了。3年前，我刚工作的时候，也考虑过这样的问题
返回顶楼
     回帖地址
0  请登录后投票
 
  • lkjust08
  • 等级: 初级会员
  • 性别: 
  • 文章: 108
  • 积分: 0
  • 来自: 北京
   发表时间：2008-12-16  
两个方面都应该考虑到就行了 
返回顶楼
     回帖地址
0  请登录后投票
 
  • hyxw5890
  • 等级: 初级会员
  • 性别: 
  • 文章: 54
  • 积分: 20
  • 来自: 南京
   发表时间：2008-12-16  
    如果不采用外键关联的话，很多字段势必得集中在一个表里面，从而造成数据冗余。根据领域模型驱动的方式设计数据库表结构，领域模型中的每一个对象只有一项职责，所以对象中的数据项不存在传递依赖，这种思路的数据库表结构设计从一开始即满足第三范式：一个表应满足第二范式，且属性间不存在传递依赖。
    如果是小项目的话，为了开发方便一点而不关联都问题不大，但要是大项目的话，感觉还是遵守规范的好
返回顶楼
     回帖地址
1  请登录后投票
 
  • hyxw5890
  • 等级: 初级会员
  • 性别: 
  • 文章: 54
  • 积分: 20
  • 来自: 南京
   发表时间：2008-12-16  
    如果不采用外键关联的话，很多字段势必得集中在一个表里面，从而造成数据冗余。根据领域模型驱动的方式设计数据库表结构，领域模型中的每一个对象只有一项职责，所以对象中的数据项不存在传递依赖，这种思路的数据库表结构设计从一开始即满足第三范式：一个表应满足第二范式，且属性间不存在传递依赖。
    如果是小项目的话，为了开发方便一点而不关联都问题不大，但要是大项目的话，感觉还是遵守规范的好
返回顶楼
     回帖地址
1  请登录后投票
 
  • sdh5724
  • 等级: 一钻会员
  • 性别: 
  • 文章: 1104
  • 积分: 970
  • 来自: 杭州
   发表时间：2008-12-16  
看你做什么样一个压力的系统了， 如果的系统是每秒要上万个交易的话， 亲爱的， 我建议你少用join吧。少于１Ｗ／Ｓ的系统，　无所谓，　怎么搞都一样的。　完整性比任何都重要，　在压力过高的时候，　妥协而已！　　我的策略就是对于主压力的表，　一般来说，　系统中总是有几个焦点表的，　数据访问压力高，　读写密集的，　这个几个表好好设计，　不要关联，把读写操作让能力好的，　经验丰富的程序员去做封装ＤＡＯ　ＡＰＩ。　其他的小表，　要做关联，　防止程序员出问题。