SQLite のフルテキスト インデックスについて多くのことを読んだ後でも、どこにも答えが見つからないという疑問が生じます。
フルテキスト インデックスを使用して検索するテーブルが既にあります。追加の仮想テーブルを作成するUSING FTS3か、データをそこに作成しますUSING FTS4。INSERT
それでは、合計で 2 倍のストレージを使用しますか? このような仮想テーブルを通常のテーブルと同じように使用して、データが 2 回保存されるのを防ぐことはできますか?
(私は Android で SQLite を使用していますが、この質問は SQLite 互換プラットフォームでの使用に適用される可能性があります。)
あなたがいくつかの詳細を見つけたという事実にもかかわらず、私は詳細な答えを提供しようとします:
1. それでは合計で 2 倍のストレージを使用しますか?
はい、そうです。さらに、イベントにより多くのスペースを使用する可能性があります。たとえば、広く知られているEnron E-Mail Dataset と FTS3 exampleの違いを感じてみてください。
通常のテーブルがわずか 1453 MB であるのに対し、FTS3 テーブルはディスク上で約 2006 MB を消費します。
通常のテーブルでは 25 分かかるのに対し、FTS3 テーブルでは 31 分弱かかりました。
これは状況を少し不快にしますが、それでも全文検索には価値があります。
2. このような仮想テーブルを通常のテーブルと同じように使用できますか?
いいえ、できません。仮想テーブルは、いくつかの制限があるある種のビューにすぎません。あなたはすでにいくつか気づいています。
一般に、 Viewにとって不自然と思われる機能は使用しないでください。アプリケーションが全文検索の機能を十分に活用できるようにするために最低限必要なものです。したがって、新しいバージョンのモジュールを使用しても、後で驚くことはありません。
このソリューションの背後に魔法はありません。これは、パフォーマンス、必要なディスク容量、および機能の間のトレードオフにすぎません。
最終的な結論
FTS4 を使用することを強くお勧めします。FTS4 の方が高速であり、唯一の欠点は追加のストレージ容量が必要になることです。
とにかく、そのようなソリューションの補足的で高度に専門化された性質を考慮して、仮想テーブルを慎重に設計する必要があります。つまり、初期テーブルを仮想テーブルに置き換えようとしないでください。どちらも大切に使ってください。
更新 次の記事に目を通しておくことをお勧めします: iOS fulltext search with Core Data and SQLite . いくつかの興味深い瞬間:
- 仮想テーブルは、コア データ コンテンツが存在する同じ SQLite データベースに作成されます。このテーブルをできるだけ軽量に保つために、検索クエリに関連するオブジェクト プロパティのみが挿入されます。
- SQLite の実装は、Core Data にない機能、つまり全文検索を提供します。それに加えて、同等の Core Data クエリよりも約 10% 高速で、少なくとも 660% 以上 (メモリ) 効率的に実行されます。
仮想テーブルの主な違いを見つけたところですが、単一のテーブルで十分かどうかは、使用法に依存しているようです。
仮想テーブルにトリガーを作成することはできません。
仮想テーブルに追加のインデックスを作成することはできません。(仮想テーブルはインデックスを持つことができますが、仮想テーブルの実装に組み込む必要があります。CREATE INDEX ステートメントを使用してインデックスを個別に追加することはできません。)
- 仮想テーブルに対して ALTER TABLE ... ADD COLUMN コマンドを実行することはできません。
そのため、テーブルに別のインデックスが必要な場合は、2 つのテーブルを使用する必要があります。