处理大量文本字符串

这些字符串平均每个300个字符。这可以是300或600字节,具体取决于Unicode设置。假设您使用 varchar(4000) 列和每个使用(平均)300字节。

然后在数据库中存储多达200000个。

存储空间不足60 MB。在数据库领域,坦率地说,就是花生。60 国标 存储是我称之为“中等”的数据库。

在这个时间点上,甚至 思考 压缩是过早的优化。SQL Server可以在不费吹灰之力的情况下处理这么多的文本。除了您没有提到的任何系统约束之外,我不会关心任何这些问题,直到并且除非您真正开始看到性能问题——即使这样,它也可能是其他问题的结果,比如糟糕的索引策略。

压缩某些类型的数据,尤其是 小的 数据量(300字节绝对很小)有时会产生更糟糕的结果。最终可能会得到比原始数据大的“压缩”数据。我猜大多数情况下,压缩后的尺寸可能会非常接近原始尺寸。

SQL Server 2008可以执行页级压缩,这将是一种更有用的优化,但您现在使用的是SQL Server 2005。所以不,绝对不要费心压缩个人 价值观 或 排 这是不值得的努力,可能实际上会使事情更糟。

如果您可以升级到SQL Server 2008,我建议您打开页面压缩,如下所示: http://msdn.microsoft.com/en-us/library/cc280449.aspx

例如,您可以创建这样的压缩表:

CREATE TABLE T1 
(c1 int, c2 nvarchar(50) )
WITH (DATA_COMPRESSION = PAGE);

如果您不能在数据库中使用压缩,很遗憾,您的字符串(不超过300个字符)不值得使用 System.IO.Compression . 不过,我想你可以试试。

压缩将消耗资源,并且通常会损害性能,其中重要的时间只是本地通信和处理。

不完全清楚你在问什么。

在性能方面——如果您在将字符串存储到数据库之前压缩内存中的字符串,那么您的程序将比直接将数据填充到表中并稍后让SQL担心的慢。权衡的是,SQL数据库将更大,但1TB硬盘驱动器是便宜的,所以存储真的有那么大的意义吗?

根据你的数字(20万字节乘以300字节),你只说大约60英里。这不是一个很大的数据集。您是否考虑过在ADO.NET中使用大容量复制功能?( http://msdn.microsoft.com/en-us/library/7ek5da1a.aspx )如果所有的数据都放在一张表中,这应该很有趣。

这将是一种替代方法,可以使用类似ef这样的工具生成基本上200K的insert语句。

更新 下面是另一个例子: http://weblogs.sqlteam.com/mladenp/archive/2006/08/26/11368.aspx

我不担心压缩它们。对于这种大小的字符串(大约300个字符),这将是一个比它的价值更令人头痛的问题。压缩字符串需要时间(不管有多小),而且SQL Server 2005没有一种本地的方法来完成这项工作,这意味着您需要编写一些东西来完成这项工作。如果在会影响性能的应用程序中执行此操作,可以在数据库中编写一个clr例程来执行此操作,但在应用程序中实际使用压缩字符串(或任何其他使用压缩字符串的方法)仍然是一个额外的步骤。

数据库中的空间很便宜,所以压缩所有字符串并不能真正节省很多空间。最大的问题是在应用程序的内存中保留大量的字符串。如果您经常返回数据库加载其中的一些内容,而不同时尝试缓存所有内容,那么除非您实际看到问题,否则我不会担心这一点。

听起来你会受益于使用 Large-Value Data Types

这些数据类型最多可存储2^31-1字节的数据

如果你所有的弦都很小,那么通过压缩它们可以获得一个递减的回报。如果没有natuve-sql压缩,那么如果您压缩它们,它们将不可搜索。

听起来您好像在试图用关系数据库解决一个绝对非关系的问题。为什么要使用数据库?当然可以,但有些问题并不适合。TFS表明,只要在RDB上投入足够的硬件,就可以强行使用它,但这并不能使它成为一个好主意。