単語のリストが 2 つあり、一致 (2 つのセットの交差) を見つける必要があります。 SQLは結合して一致を見つけますか?
3 に答える
問題についてのより多くの情報なしで言うことはほとんど不可能です。考慮すべき点がいくつかあります。
- 異なるアイテムはいくつありますか?
- 典型的な列にはいくつの異なる組み合わせがありますか?
- 検索でワイルドカードを探す必要がありますか?
- 個々のアイテムの長さはどれくらいですか?
- 実行しているデータベースエンジンとハードウェアの詳細。
ほとんどすべての状況で、値を別のテーブルに格納する必要があることを強調したいと思います。パフォーマンスが必ずしも主な理由ではありません。さらに重要なのは、個々の値の更新と削除の容易さ、およびより多くのタイプのクエリ(使用可能なすべての値のリストなど)をサポートする機能です。
ただし、パフォーマンスの問題についてはまだ考えることができます。単一の文字列に値を格納するには、レコードが含まれているページをフェッチしてから、文字列を処理する関数を適用するだけです。単純なパターン(固定部分文字列の存在の識別など)の場合、これは非常に高速に実行されます。文字列をループして値を比較するよりもコンピュータが高速に実行することはほとんどありません(適切な実装を前提としています)。
可能な限り最速の結合では、両方のテーブルを読み込む必要があり、キーを一致させる必要があります。これには追加の作業が必要です。状況はさらに悪化します。1つは個々の文字列アイテム用で、もう1つは元のレコードとアイテム間の関係用の2つの追加テーブルが必要だからです。
この時点で、「まあ、文字列はより良いアイデアのように思える」と思うかもしれません。これは間違っています。大きな違いの1つは、平均サイズです。アイテムが平均して4文字より長い場合は、参照テーブルを使用してスペースを節約します。この節約されたスペースは、I / Oが少ないため、すぐにパフォーマンスの向上につながります。インデックスを使用すると、追加のテーブルはとにかくメモリ内にあるため、マッチングは非常に高速になります。
そして、クエリの問題があります。AとBを持つレコードなどのクエリには標準のSQL関数を使用できます(多くの文字列関数はデータベース固有です)。データベースにあるアイテムを正確に簡単に見つけることができ、レコードに存在するペアを比較的簡単に見つけることができます。アイテムがレコードに追加されたときと、データベースに最初に表示されたときを追跡できます。一般に、この柔軟な機能(基本的なSQL機能)は、このタイプのデータを管理するときに必要なものです。
私はあなたがこれを求めていると思います:
SELECT word FROM table_one WHERE word in (SELECT word FROM table_two)
これよりも高速です:
SELECT table_one.word FROM table_one
INNER JOIN table_two ON table_one.word = table_two.word
2番目の答えは(潜在的に大きな)一時オブジェクト(結合されたテーブル)を作成するため、最初の答えはより速くなるはずです。
にインデックスがあると仮定していることに注意してくださいword
。また、文字列が非常に長い場合(たとえば、URL)、これは非常に遅くなるため、代わりにハッシュで一致させる必要があります。
テーブルへの格納は、特に単語にインデックスを付けることができる場合、ほとんどの状況で SQL 文字列操作関数よりもはるかに高速です。