Ну если хотите продолжать в этом направлении, то для поиска можно и хеширование использовать или контрольную сумму, не обязательно кодировать сжатием. Создать индекс по хешам и методом дихотомии выполнять поиск.
Но это при наличии исходной порции в полном объеме.
Я например, в подобных случаях использую СУБД без всяких выкрутасов. И времени меньше затрачиваю на разработку, и продукт стабильный получается.
再挑戦中です。
3つのファイルを用意しました。
1.L.トルストイ戦争と平和 第1巻
2.L.トルストイ戦争と平和」第2巻
3.F・ドストエフスキー罪と罰
それぞれを梱包します。
名前のないパックされたファイルが3つあります（ただ、名前のないファイルをどう想像するかは聞かないでください）。また、パッケージではないファイルも1つあり、『罪と罰』とさせてください。
3つの圧縮ファイルの中から、最も経済的な方法でこのファイルを見つけるにはどうしたらよいでしょうか。
オプション1：3つのファイルをすべて解凍して、探しているファイルを見つける。
オプション2.探しているファイルを圧縮し、3つの圧縮されたファイルの中から全く同じファイルを探します。
うんうん - だから、あなたが提案したものはダメなんだ
そうですね、データが短いとアーカイブするときにサイズが大きくなってしまうのはわかります。
この方向でいくなら、ハッシュやチェックサムを使った検索も可能なので、圧縮符号化を使わなくてもいいんです。ハッシュインデックスを作成し、二項対立で検索する。
ただし、ソース部分がフルサイズで利用できる場合です。
例えば、こういう場合は、何も工夫せずにDBMSを使うんです。開発に費やす時間も少なく、製品も安定しています。
皆さんは正しいことをおっしゃっていますが、これで改めて、圧縮オプションはタスクのために正当化されるべきものであることが強調されました。
問題文に頼らざるを得ない。
この方向でいくなら、ハッシュやチェックサムを使った検索も可能なので、圧縮符号化を使わなくてもいいんです。ハッシュインデックスを作成し、二項対立で検索する。
ただし、ソース部分がフルサイズで利用できる場合です。
例えば、こういう場合は、何も工夫せずにDBMSを使うんです。開発に費やす時間も少なく、製品も安定しています。
だから、私の提案ではないんです。いずれにしても発想は面白い。
>>> 2つの圧縮された配列を比較する話。
デミ！そういえば、こんな話もありましたね。
>>>それこそ、実際に議論した通りです。
>>>そうですね、データが短いとアーカイブするときにサイズが大きくなってしまいますね。
>> だからダメなんだよ
--
だから、産業用データベースにはその思想がないんです。
...
Ну если хотите продолжать в этом направлении, то для поиска можно и хеширование использовать или контрольную сумму, не обязательно кодировать сжатием. Создать индекс по хешам и методом дихотомии выполнять поиск.
Но это при наличии исходной порции в полном объеме.
Я например, в подобных случаях использую СУБД без всяких выкрутасов. И времени меньше затрачиваю на разработку, и продукт стабильный получается.
整数。
良いアイデアですね。やってみるがよい
>>> 例えば、こういう場合、私は何の仕掛けも なく DBMSを使っています。開発期間も短く、製品も安定しています。
が、既製の産業用SQLデータベースを使用した方が良い。
>>> 2つの圧縮された配列を比較する話。
デミ！そういえば、こんな話をしていたね。
>>>それこそ、実際に議論した通りです。
>>>そうですね、データが短いとアーカイブ時にサイズが大きくなってしまいますね。
>> だからダメなんだよ
--
だから、産業基地にはそういう思想もない。
...
やってみるがよい
>>>私などは、そのような場合、小細 工なしの DBMSを使います。開発に費やす時間も少なく、製品も安定しています。
が、既製の産業用SQLデータベースを使うのがベストです
ユリチク ファイル加工や圧縮などの紆余曲折を経ずにということです。SQLとロボット・インジケータのロジックを扱うだけという意味です。私は多くのデータベースを扱いましたが、唯一の問題はMQLとSQLを一緒に動作させることでした))。 私は配列や構造体を使わないで、見栄えの良いソリューションを作りました。
一般的に、私は車輪の再発明をせず、最適な手段で問題を解決することを好みます。
それは別の理由だと思います。OSに大きなデータを読み込む問題は、そこでは解決方法が異なるため、読み込まず、ディスクから直接読み込むことになる。(だろう）
サーバーがやってくれる...非常に効率的です。