|
锁定老帖子 主题：数据库的设计原则：关联还是不关联？
精华帖 (2) :: 良好帖 (0) :: 新手帖 (8) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-12-07
我建议您还是不要关联 自己用自己的业务逻辑比较好
|
| 返回顶楼 | |
|
发表时间：2009-12-09
开发经验丰不丰富也没啥关系吧
应用层逻辑不可靠，测试难道不能测出来么 ls有个哥们说得好，自己有把握就自己处理关联关系，没把握就用数据库 jasonshi 写道 除了极端性能要求的情况下，外键是不嫌多的。
大部分的应用，读多写少，外键的性能影响几乎可以忽略，只要索引合适就行。 通常软件开发经验越丰富，越是会知道关联/外键的好处。 应用层的校验不可靠的，外键就是为了防止应用层逻辑的不可靠。 |
| 返回顶楼 | |
|
发表时间：2009-12-14
carlkkx 写道 很多人都强调数据完整性，但是现实世界是数据往往要容错的，而且完整性并不是要同一时间保证的，比如你填一份表格，有几个栏位不确定，但是已经填的需要放入，没填的等明确了再填，但是数据库约束却认为这份数据是不合法的，无法加入，岂不是很不好的体验。数据完整性现实世界操作往往不是同一时间完成的，但是电脑却蛮横无理要求一定要满足了才能放入，是很糟糕的体验。
这是最不负责任的作法。分析时不管业务意义上的约束，而是放开所有约束。等到生产环境出现了脏数据，一句“用户使用不规范”就给打发了。 |
| 返回顶楼 | |
|
发表时间：2009-12-15
iamlotus 写道 carlkkx 写道 很多人都强调数据完整性，但是现实世界是数据往往要容错的，而且完整性并不是要同一时间保证的，比如你填一份表格，有几个栏位不确定，但是已经填的需要放入，没填的等明确了再填，但是数据库约束却认为这份数据是不合法的，无法加入，岂不是很不好的体验。数据完整性现实世界操作往往不是同一时间完成的，但是电脑却蛮横无理要求一定要满足了才能放入，是很糟糕的体验。
这是最不负责任的作法。分析时不管业务意义上的约束，而是放开所有约束。等到生产环境出现了脏数据，一句“用户使用不规范”就给打发了。 你给党国的某些部门做事儿，约束性太强了，那些人还以为你的系统有问题呢 |
| 返回顶楼 | |
|
发表时间：2009-12-15
大家的case都不大一样, 结论自然不同.
偶是做c/s的, 数据要在远程传递, lazy的话序列化和jaxb都会有问题. 不lazy效率不高. 做b/s的可能没这个问题. 另外, 我觉得hibernate validation框架应该解决这个问题. 加上一个@FK属性就行了, 不要总干些拔出萝卜带出泥的事情. 另外, 强壮的系统似乎不应该依靠关联来检查错误, 就是报错信息也不好看. 查询效率问题, 冗余啊, 视图啊, 缓存啊都可以, 看数据量,效率了 偶准备做个POJO driven framework, 这个关联准备交给框架处理, 不要在数据库层面折腾. |
| 返回顶楼 | |
