データベース内の全文検索に関する2つの質問があります。私は弾力的な検索とソルを探していました。テーブルエントリーで構成された別々の文書を作成して検索する必要があるようです。そのような検索の結果は、実際にはデータベースエントリではありませんか？それとも私は何かを誤解しましたか？データベース内の全文検索
また、インデックステーブルの列とwhooshの結果が実際のテーブル行であるwhoosh検索について調べました。 ソルバーまたはエラスティック検索を使用する場合、検索するドキュメントに行IDを入れて、その結果を使用してテーブルから関連する行を取得する必要がありますか？または、より良い解決策がありますか？
私が持っている別の質問は、文字列として格納されているabc/123.64664のようなIDがあれば、FTSでそのような列を検索する利点はありますか？私には索引付けによって得られるべきことはあまりありません。または私は間違っていますか？ ありがとう
Elasticsearchはインデックス付きドキュメントを保存でき、クエリ結果の一部として取得できます。通常、pplは元のデータを通常のDBに保存していますので、再インデックスの信頼性と柔軟性が向上します。 ESが非リレーショナルデータのインデックスを作成することを覚えておいてください。リレーショナル方式でデータを保存し、索引付けのために非正規化文書を作成することができます。
あなたがなどの接頭辞検索用のトークン化文字列またはあなたのように、インデックス、それは調整できインデックスをすることができます「ABC/123.64664」のためとして、それはあなた次第です
（TL; DR）が何を考えてはいけませんあなたのデータはRDBSで構造化されています。あなたが何であるか考えてくださいを検索します。
良好な全文検索のためのコンテンツストレージは、リレーショナルデータベースの標準ストレージとはかなり異なります。したがって、検索エンジンに入るデータは、保存した方法とはまったく異なった外観になる可能性があります。
これはすべてあなたの期待通りに駆動されます検索結果。データの細かさを増やしたり、反対の逆正規化をして、親/関連レコードの内容が検索の一部として実際に返されるレコードに表示されるようにすることができます。テキスト処理（コピーフィールド、トークン化、前処理など）は、レコードを検索可能にするために多くのコンテンツ変更が行われる場所でもあります。
リレーショナルデータベースでは、フルテキスト検索がサポートされることがあります。 PostgreSQLはより良くなりました。しかし、ほとんどの場合、リレーショナルデータベースは関連性の高い検索をサポートするのに十分な柔軟性を提供していません。
最後に、元のスキーマが非常に複雑な場合は、検索エンジンを使用して権利関連のIDを取得し、クライアントコードで元のデータベースレコードの詳細とマージするだけです。