按需要分多表存储吧,image读取本来就比较慢,记录量很大的很大,肯定不好处理.

解决方案 »

  1.   

    Image字段在表中存储的只是一个指针,几万条数据不是大数目,没必要分表
      

  2.   

    哈哈,感觉没必要分表,
    一个文件1M,听说有上十万个,就是10W 个M,
    是有点大啦
      

  3.   

    提醒LZ:由 ntext、text 或 image 数据类型组成的列不能指定为索引列。
      

  4.   

    没有必要分表存储。不过在实现是应尽量避免一次取出太多条记录的Text字段,该字段的信息应只在有必要的时候取出。LZ不妨造些数据做个压力测试。
      

  5.   

    倾向于还是让文件本身入库。我曾经也有同样的疑问,也做过个比较粗糙的测试,初步认为少量用户性能上应该无大碍。我的测试库有5万个文件,从几十K到几M都有,约15G。测试服务器就是用个淘汰的PC,赛扬1G/320M/XP SP2 + SQL 2005 开发版,挂3个客户端没有发现明显性能问题。我认为如果不存入数据库,磁盘上的10万个零碎小文件维护起来也是件相当相当头痛的事情。但据我所知PACS之类的医学影像系统一般并不把图片本身直接入库(那个容量太恐怖了),但在文件的存储组织上很讲究,楼主如果最后还是决定不入库的话不妨可以参考一下这类系统的文件组织方式。