|
锁定老帖子 主题：对数据表中大字段的处理方式
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-11-01
我公司的有一套系统，近1年的附件已达到70+G，如果放到库里那只有找死。所以还要具体问题具体分析，附件数据量小的，可以考虑入库。
|
| 返回顶楼 | |
|
发表时间：2006-11-09
zelsa 写道 我公司的有一套系统，近1年的附件已达到70+G，如果放到库里那只有找死。所以还要具体问题具体分析，附件数据量小的，可以考虑入库。
如果这些附件都放在一个单独的表里,通过外键关联到其他表,这样又不影响其他表,怎么会是找死? 难道70G的文件系统就不是找死? |
| 返回顶楼 | |
|
发表时间：2006-11-09
向高手学习
|
| 返回顶楼 | |
|
发表时间：2006-11-16
好贴子
|
| 返回顶楼 | |
|
发表时间：2006-11-17
需要高手支持,需要反复考察验证方可定论,支持讨论...
|
| 返回顶楼 | |
|
发表时间：2006-12-04
大数据量下的LOB处理没有捷径，目前唯一合理的方法是：
专用文件服务器＋基于数据库的目录管理 希望改个Pojo细节，躲开LOB字段的映射就能解决问题是不现实的，问题的瓶颈就是数据库本身。 |
| 返回顶楼 | |
|
发表时间：2006-12-07
能不能说说INDEX表的具体做法。
|
| 返回顶楼 | |
|
发表时间：2006-12-07
我觉得放到文件系统的优势是对于可以公开访问的大数据，如个人头像的图片，帖子的正文等可以外部访问的东西，可以通过Apache直接读取，完全不用经过App和DB层，这对性能优化是非常有用的。 cookoo 写道 放在数据库里可以直接利用数据库的安全性，完整性，备份，集群，远程可访问性。当然设计不好的话对性能会有影响。
如果放在文件系统，数据库里只保留一个path的话，虽然本地访问直观，但是同步检查（检查path所指文件是否真的存在），加上上述各种数据库特性就都需要自己来处理了。 |
| 返回顶楼 | |
|
发表时间：2006-12-21
能不能说说INDEX表的具体做法。
|
| 返回顶楼 | |
|
发表时间：2007-03-23
试过hibernate 的话大字段的属性都设lazy＝true，能提高查询速度。具体能提高多少不知道了
|
| 返回顶楼 | |
