62,047
社区成员
发帖
与我相关
我的任务
分享我想在数据表中加个冗余字段，方便查询用，有什么弊端吗？谢谢
除了数据表看起来越来越复杂，数据量大了一些，多了一些冗余字段，其他还有没有什么不好的弊端？
我只是想查询的时候少关联几个表，少join几次，谢谢
我只是想查询的时候少关联几个表，少join几次，谢谢
...全文
请发表友善的回复…
发表回复
缪军 2009-09-29
- 打赏
- 举报
数据库设计的步骤应该是
规范化->反规范,
但是楼主的情况不属于反规范范畴,
主外键关系不会导致性能的下降,
要想简化代码应该通过建立视图的手段,
视图设计、标量函数、表值函数都是数据库设计的一部分,
规范化->反规范,
但是楼主的情况不属于反规范范畴,
主外键关系不会导致性能的下降,
要想简化代码应该通过建立视图的手段,
视图设计、标量函数、表值函数都是数据库设计的一部分,
wowtdgd 2009-09-29
- 打赏
- 举报
越来越清晰了。
现在就想知道数据库的数据量大的弊端是什么呢？完了就结贴啦，感谢兄弟们！
现在就想知道数据库的数据量大的弊端是什么呢？完了就结贴啦，感谢兄弟们！
puzhichen 2009-09-29
- 打赏
- 举报
事实证明,商业运用时,需求往往和3范式冲突
一般人都是放弃性能而选择速度.
一般人都是放弃性能而选择速度.
冷眼1983 2009-09-29
- 打赏
- 举报
完全可以的，完全支持。 现在硬件 无数牛了， 而且减少连接，增加了查询的速度
ViewStates 2009-09-29
- 打赏
- 举报
一般加的这种字段都是其他表的主键或者不是很好查出来的信息，我一般用的时候这种字段容量都很小，比如状态啊什么什么的，而且这种字段都会有很明确的意义。
你这个地方几百个字符我都认为有些大了，你应该先考虑下你现在数据库设计的是否合理，如果在数据库已经定型，不能做大更改的情况下你也只能自己做权衡了，数据库本身就是存放数据的，你管他是1个字节还是1M字节呢？
你这个地方几百个字符我都认为有些大了，你应该先考虑下你现在数据库设计的是否合理，如果在数据库已经定型，不能做大更改的情况下你也只能自己做权衡了，数据库本身就是存放数据的，你管他是1个字节还是1M字节呢？
JGood 2009-09-29
- 打赏
- 举报
并不是在任何情况下都必须遵守第三范式的。
wowtdgd 2009-09-29
- 打赏
- 举报
。。。那数据库容量大了有什么弊端吗？？
我这个冗余字段撑死也不过几百个字符。。。
如果是几十万的字符呢？求教，谢谢楼上几位大哥先
我这个冗余字段撑死也不过几百个字符。。。
如果是几十万的字符呢？求教，谢谢楼上几位大哥先
哈喽Baby 2009-09-29
- 打赏
- 举报
现实的数据库设计允许数据冗余的
chen_ya_ping 2009-09-29
- 打赏
- 举报
这个就要看你的设计情况了，要是你觉得方便，那就可以用不一定什么都要按照规范来。
Chris_thanks 2009-09-29
- 打赏
- 举报
空间换时间，自己取舍下吧，记得记录到文档去
randomfeel 2009-09-29
- 打赏
- 举报
数据库设计还是要根据业务需求灵活变通，不用完全按照三大范式的要求
加个字段减少了join，就要考虑两边同步的问题了
加个字段减少了join，就要考虑两边同步的问题了
zzxap 2009-09-29
- 打赏
- 举报
速度快了，容量大了
CODE163 2009-09-29
- 打赏
- 举报
看情况 如果不加严重影响效率那肯定还是加了好！
wowtdgd 2009-09-29
- 打赏
- 举报
规范害死人啊。。。
ViewStates 2009-09-29
- 打赏
- 举报
根据数据库设计规范这种字段是不应该存在的。
但是我感觉在实际中有些时候加不加这个冗余字段对查询效率和难易度差别很大。这个我感觉只能是自己来取舍。加个字段无疑查询上速度和难度上都可以得到很大的益处，但加了字段也会带来需要维护这个冗余字段的麻烦。
但是我感觉在实际中有些时候加不加这个冗余字段对查询效率和难易度差别很大。这个我感觉只能是自己来取舍。加个字段无疑查询上速度和难度上都可以得到很大的益处，但加了字段也会带来需要维护这个冗余字段的麻烦。
