数据库效率不够高吧，而且文件大小从2k到100k都有

@Ray Wu: 高的。

对文件分大小存储，小文件直接存储在数据库里面，大文件存储在文件系统中。

我的实现方案是：

1、专门定义两个数据表：A用于记录所有的数据文件，B用来记录大数据文件

2、对于大数据文件，在A中只存储文件基本信息，不存储文件内容（binary字段内容置空），数据内容链接到B表中

3、B表存储的二进制字段转换为文件流的方式存储。

按照MS的建议，对于大于1M的二进制数据流，最好在数据库里以文件流的方式存储，而低于1M的文件则直接存储在数据库里，这样的整体操作效率最高。

我做过实验，把大小定义在500K的时候，在我的系统里性能不错（系统是普通PC机，使用E2双CPU，4G内存）。

@519740105: 好的，非常感谢，到时我们打他放到数据库里面试一下看看。我们的文件99%都是低于100K的，应该还是挺适合的

@519740105: 使用数据库存储小文件，用nvarchar(max)字段是不是最优化的？

@Ray Wu: 最好用binary。

1、binary也是最大的，但是基于二进制，可以保存各类文件，而nvarchar(max）只能针对文本

2、binary才可以通过filestream技术保存到文件，nvarchar(max)是不可以的

3、binary读取的数据是字节数组，属于引用类型，而nvarchar(max)读取的是字符串，虽然也是引用类型，但是在实际操作中却类似值类型，同时，内存操作的性能也不如字节数组。

@519740105: 好的，不过我们的情况比较特殊，我们的文件都是文本文件，另外，我们的文件大小基本上没有超过100K的，所以这种情况是不是用nvarchar(max)是更好的？

@Ray Wu: 看起来，貌似可以使用nvarchar(max)，实际还是不好。

1、如我前面所言，binary可以支持文本外的数据，如果今后有需求变化呢？

2、如我前面所言，一个大到100K的字符串，那是怎样的概念？

3、nvarchar会限制你的文本内容编码，而binary则没这个限制。

@519740105: 嗯，我们这个需求是肯定不会变的，因为我们现在就是几百万个小文件放在文件系统，现在打算迁移到数据库（这样可以提供远程访问功能，同时备份与迁移等都要更方便）。

binary从整体来说可能更好，只是效率方面用nvarchar是不是会更好，毕竟直接就是文本，默认肯定是UTF-8编码，因为我们的文本文件都是XML文件。

@Ray Wu: 这个就没对比过在数据库层是否二进制流的性能比字符串更好，个人的理解与认识而言，还是不建议用nvarchar(max)。

@519740105: 嗯，我们决定使用varbinary，使用varbinary需要调用System.Text.Encoding.UTF8.GetString和System.Text.Encoding.UTF8.GetByte进行转移，但是应该是可以节省存储空间的。因为nvarchar是通过utf-16存储的，而我的编码实际上是UTF-8，UTF-16多占用了很多空间。

@Ray Wu: 对。varbinary跟binary其实是一致的，区别不是很大，酌情处理就好。

@519740105: 是的，不过binary的最大大小是8000个字节

@519740105: 请教一个问题，你说的大于1M以文件流的方式存储是指的类似mysql里面的blob类型么？那小于1M直接存储是怎么存储？这个我不是很懂，望抽空回复一下