Ну если хотите продолжать в этом направлении, то для поиска можно и хеширование использовать или контрольную сумму, не обязательно кодировать сжатием. Создать индекс по хешам и методом дихотомии выполнять поиск.
Но это при наличии исходной порции в полном объеме.
Я например, в подобных случаях использую СУБД без всяких выкрутасов. И времени меньше затрачиваю на разработку, и продукт стабильный получается.
我再试一次。
我们有三个文件。
1.L.托尔斯泰。战争与和平》第一卷。
2.L.托尔斯泰。战争与和平》第二卷。
3.F. 陀思妥耶夫斯基。罪与罚》。
我们为他们每个人打包。
我们有三个没有名字的打包文件（只是不要问我如何想象一个没有名字的文件）。我们也有一个非包装文件，就让它成为 "罪与罚"。
如何以最经济的方式在三个压缩文件中找到这个文件？
选项1：我需要压缩所有三个文件并找到我正在寻找的文件。
选项2。压缩你要找的文件，在三个压缩的文件中找到完全相同的文件。
是的，我知道，如果数据很短，归档时大小会增加。
如果你想继续朝这个方向发展，你也可以使用散列或校验来搜索，你不必使用压缩编码。创建一个哈希索引并通过二分法搜索。
但这是在来源部分有全尺寸的情况下。
例如，在这种情况下，我使用DBMS，没有任何花招。我花在开发上的时间更少，产品也很稳定。
你们说的都是对的，这再一次强调了压缩选项应该是合理的任务。
你必须依靠问题陈述。
如果你想继续朝这个方向发展，你也可以使用散列或校验来搜索，你不必使用压缩编码。创建一个哈希索引并通过二分法搜索。
但这是在来源部分有全尺寸的情况下。
例如，在这种情况下，我使用DBMS，没有任何花招。我花在开发上的时间更少，而且产品很稳定。
所以这不是我的建议。无论如何，这个想法是有趣的。
>> 谈到比较两个压缩的序列。
迪马！提醒我--这就是我们谈论的内容。
>> 这正是我们在实践中讨论的。
>> 是的，我知道，如果数据很短，归档时就会增加大小。
>>这就是为什么它没有用的原因
--
这就是为什么工业数据库没有这种意识形态。
...
Ну если хотите продолжать в этом направлении, то для поиска можно и хеширование использовать или контрольную сумму, не обязательно кодировать сжатием. Создать индекс по хешам и методом дихотомии выполнять поиск.
Но это при наличии исходной порции в полном объеме.
Я например, в подобных случаях использую СУБД без всяких выкрутасов. И времени меньше затрачиваю на разработку, и продукт стабильный получается.
整数。
好主意。你可以试试
>> 例如，在这种情况下，我使用DBMS ，没有任何花招。它的开发时间较短，而且产品很稳定。
但最好是使用一个现成的工业SQL数据库
>> 谈到比较两个压缩的序列。
迪马！提醒我--这就是我们正在谈论的东西
>> 这正是我们在实践中讨论的。
>> 是的，我知道，如果数据很短，在归档时就会增加尺寸。
>>这就是为什么它没有用的原因
--
这就是为什么工业基地也没有这种意识形态的原因
...
你可以试试
>> 例如我，在这种情况下，使用一个 没有任何技巧 的DBMS。我花在开发上的时间更少，而且产品很稳定。
但最好是使用现成的工业SQL数据库
Yurichik，我的意思是没有任何曲折的文件处理、压缩等。我的意思是只用SQL和机器人/指示器逻辑工作。我与许多数据库合作，唯一的问题是使MQL和SQL一起工作））。 我创建了一个漂亮的解决方案，没有数组和结构。
一般来说，我不喜欢重新发明轮子，而是用最好的手段解决问题。
我认为这是另一个原因。因为在那里以不同的方式解决了向操作系统加载大数据的问题，它们不是被加载，而是直接从磁盘上读取。(我猜)
服务器会做...非常有效。