複数の店舗を持つ電子商取引アプリケーションを考えてみましょう。各ストア オーナーは、自分のストアのアイテム カタログを編集できます。
私の現在のデータベーススキーマは次のとおりです。
item_names: id | name | description | picture | common(BOOL)
items: id | item_name_id | picture | price | description | picture
item_synonyms: id | item_name_id | name | error(BOOL)
注:errorスペルが間違っていることを示します (例: "Ericson")。descriptionおよびテーブルの「グローバル」pictureは、「ローカル」およびテーブルのフィールドによってオプションでオーバーライドできる(店舗の所有者がアイテムに別の画像を提供したい場合)。一意のアイテム名を区別するのに役立ちます (「ジミー ジョーズ チーズ ピザ」と「チーズ ピザ」)item_names descriptionpictureitemscommon
このスキーマの明るい面は次のとおりだと思います。
最適化された検索とシノニムの処理:item_names &item_synonymsテーブルを使用してクエリを実行し、テーブルと結合する必要がある のname LIKE %QUERY%リストを取得できます。（同義語の例：「Sony Ericsson」、「Sony Ericsson」、「X10」、「X 10」）item_name_iditems
オートコンプリート:繰り返しますが、item_namesテーブルへの単純なクエリです。DISTINCT（「Sony Ericsson Xperia™ X10」、「Sony Ericsson - Xperia X10」、「Xperia X10、Sony Ericsson」）の使用を避けることができ、バリエーションの数を最小限に抑えることができます。
マイナス面は次のとおりです。
オーバーヘッド:項目を挿入するときにitem_names、この名前が既に存在するかどうかを確認するためにクエリを実行します。そうでない場合は、新しいエントリを作成します。アイテムを削除するとき、同じ名前のエントリの数を数えます。これがその名前を持つ唯一のアイテムである場合、item_namesテーブルからエントリを削除します (単に物事をきれいに保つためです。誤った提出の可能性を考慮します)。そして、更新は両方の組み合わせです。
奇妙な商品名:店主は、「Harry Potter 1, 2 Books + CDs + Magic Hat」のような文章を使用することがあります。このようなケースに対応するために、これほど多くのオーバーヘッドが発生することには何か問題があります。これがおそらく、次のようなスキーマを使用したくなる主な理由です。
items: id | name | picture | price | description | picture
（...クエリできるユーティリティテーブルと一緒にitem_names）item_synonyms
- あなたが提案したより良いスキーマはありますか?
- オートコンプリートのためにアイテム名を正規化する必要がありますか? これはおそらく、Facebook が「学校」、「都市」のエントリに対して行うことでしょうか?
- 最初のスキーマと 2 番目のスキーマのどちらが検索に適していますか?
前もって感謝します！
参考文献: (1)人の名前を正規化するのは行き過ぎですか? 、(2) DISTINCTの回避
編集:類似した名前で 2 つの項目が入力された場合、これを見た管理者は、[シノニムにする] をクリックするだけで、名前の 1 つが別のシノニムに変換されます。入力された名前が他の名前の同義語であるかどうかを自動的に検出する方法は必要ありません。オートコンプリートがそのようなケースの 95% を処理してくれることを願っています。テーブル セットのサイズが大きくなるにつれて、「シノニムの作成」の必要性は減少します。混乱が解消されることを願っています。
更新:私が何を進めたかを知りたい方へ... 2 番目のスキーマを使用しましたが、 Solrが必要な残りのすべてのタスクを実行する機能を提供してくれることを期待して、item_namesとitem_synonymsテーブルを削除しました:
items: id | name | picture | price | description | picture
助けてくれてありがとう！