|
锁定老帖子 主题：数据库的设计原则：关联还是不关联？
精华帖 (2) :: 良好帖 (0) :: 新手帖 (8) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-03-26
我们项目的关联（一般来说就是FK）都是在应用级别做逻辑关联的，在数据库级别没有做。暂时还没出现什么大问题
|
| 返回顶楼 | |
|
发表时间：2009-03-28
chenkan2000 写道 关系数据库当然要建关联，2NF总是要的。不然极有可能出现错误数据，如员工所属的部门，在部门信息表中不存在，这会导致程序出错。当然你可以增加判断，但太麻烦了，用了关联，数据库就可以帮你解决掉这个问题。
至于关联会影响性能的问题，你难道做的是数据仓库？ 在hibernate配置中也建议用关联，因为没有关联，hql的外连接是不行的。而且代码可以更OO。 因为没有关联，hql的外连接是不行的? 有这回事？ |
| 返回顶楼 | |
|
发表时间：2009-03-28
Hibernate之所以在处理大批量数据的时候效率慢就是因为这个关联问题。有时候设计不好了可能会多出一些很没必要的查询
个人认为还是具体情况具体分析，没有绝对的概念。需要关联的就关联，能不关联的就不关联 |
| 返回顶楼 | |
|
发表时间：2009-03-28
魔力猫咪 写道 建议进行关联。那些所谓的什么为了性能什么范式也不管的话不过是他自己数据库能力不过关罢了。
很多时候所谓的“按照范式速度太慢”其实不过是SQL写得太差而已。还有就是索引使用不合理，造成性能损失。索引不是随便乱加的，每加一个，造成的CUD性能损失可不小。 建议你看看《SQL语言艺术》这本书。你每一个冗余都就会造成数据维护困难，备份占地方，恢复速度变慢等问题。 而且你可以通过各种缓存进行缓冲，现在很多人特别是一些以前的开发人员，特别爱吃老本，对缓存及其不信任，什么都想存数据库里，什么都直接从那里读。很多复杂的查询对时间的有效性都是不太敏感的，完全可以使用缓存来减轻压力。 我最近也在看SQL语言艺术，看完才知道，咱们很多所谓因为表关联导致的性能问题，究其根本是SQL的基础不够过硬，比如什么情况使用子查询，什么情况使用join查询等等，里面门道还是很多的。 |
| 返回顶楼 | |
|
发表时间：2009-03-31
【我们项目的关联（一般来说就是FK）都是在应用级别做逻辑关联的，在数据库级别没有做】
严重同意这种做法，hibernate的关联写法和用法是编程中的难点。 |
| 返回顶楼 | |
|
发表时间：2009-03-31
javacc 写道 chenkan2000 写道 关系数据库当然要建关联，2NF总是要的。不然极有可能出现错误数据，如员工所属的部门，在部门信息表中不存在，这会导致程序出错。当然你可以增加判断，但太麻烦了，用了关联，数据库就可以帮你解决掉这个问题。
至于关联会影响性能的问题，你难道做的是数据仓库？ 在hibernate配置中也建议用关联，因为没有关联，hql的外连接是不行的。而且代码可以更OO。 因为没有关联，hql的外连接是不行的? 有这回事？ 是的。 |
| 返回顶楼 | |
|
发表时间：2009-03-31
这个要看业务需求，在某些时候，就需要这种关联，可以快速查询出与子表的数据
|
| 返回顶楼 | |
|
发表时间：2009-04-03
数据库表分类,核心的表有外键,页面可操作表的无关联,通过batch定时处理外围表,维护数据正确性,外加无数的备份表XXX_bak
也有完全无关联的，开发很爽，但是测试bug一堆，测试难度也很大，但是表结构很直观，如果不怕字段多麻烦的话，可以减少很多sql语句。感觉对于java开发，无关联的能体现出java的特点，而且关联逻辑转化成java对象，编码时候可以面对更明了的对象，提高不少效率 |
| 返回顶楼 | |
|
发表时间：2009-04-03
小项目可以用关联， 大项目尤其是海量数据的表不要关联，由程序自己做关联。 这是一个很牛逼的Oracle DBA 的结论！ |
| 返回顶楼 | |
|
发表时间：2009-07-17
bizzad 写道 我们现在这个做了4年还在做，200m，50多万行的项目现在是倾向于完全不建关联了，新的数据模型一律不考虑关联
严重同意 |
| 返回顶楼 | |
