数据库的设计原则：关联还是不关联？ 设计网站数据库（确定使用Hibernate）的过程中，时常会有争论，争论的焦点主要还是集中在表与表之间的关联上面： 有的倾向于去掉表与表之间的任何关联；有的拿完整性说话，必须保留所有的关联性。 观点1： 我倾向于去掉
数据库的设计原则：关联还是不关联？
设计网站数据库（确定使用Hibernate）的过程中，时常会有争论，争论的焦点主要还是集中在表与表之间的关联上面：
有的倾向于去掉表与表之间的任何关联；有的拿完整性说话，必须保留所有的关联性。
观点1：我倾向于去掉所有的关联，为了开发的方便。然后写代码的时候自己留意完整性的问题。
观点2：
如果不采用外键关联的话，很多字段势必得集中在一个表里面，从而造成数据冗余。根据领域模型驱动的方式设计数据库表结构，领域模型中的每一个对象只有一项职责，所以对象中的数据项不存在传递依赖，这种思路的数据库表结构设计从一开始即满足第三范式：一个表应满足第二范式，且属性间不存在传递依赖。
如果是小项目的话，为了开发方便一点而不关联都问题不大，但要是大项目的话，感觉还是遵守规范的好
观点3：
看你做什么样一个压力的系统了， 如果的系统是每秒要上万个交易的话， 亲爱的， 我建议你少用join吧。少于１Ｗ／Ｓ的系统， 无所谓， 怎么搞都一样的。 完整性比任何都重要， 在压力过高的时候， 妥协而已！ 我的策略就是对于主压力的表， 一般来说， 系统中总是有几个焦点表的， 数据访问压力高， 读写密集的， 这个几个表好好设计， 不要关联，把读写操作让能力好的， 经验丰富的程序员去做封装ＤＡＯ ＡＰＩ。 其他的小表， 要做关联， 防止程序员出问题。我们现在这个做了4年还在做，200m，50多万行的项目现在是倾向于完全不建关联了，新的数据模型一律不考虑关联
观点4：
开发语言：java，支持数据库：Mysql 5，系统架构：J2EE，操作系统：linux/Windows1. 引言 32. 系统的结构 32.1 系统概述 33. 功能模块设计说明 43.1 商品管理 43.1.1 添加商品功能模块 53.1.2 商品列表功能模块 83.1.3 商品关联功能模块 93.
具体情况具体分析
业务表 我认为关联要好
而有一些历史信息比如日志什么的，我基本都不关联，而且最大冗余~
我的观点：
db方面经验不足，暂不发表意见。
