3

私は、ユーザーが販売しているさまざまな種類のアイテムの詳細なフィールドを含む求人広告を投稿できるWebサイトをプログラミングしています。ただし、最適なデータベーススキーマについて質問があります。

このサイトには多くのカテゴリ（自動車、コンピュータ、カメラなど）があり、広告の各カテゴリには独自のフィールドがあります。たとえば、車にはドアの数、メーカー、モデル、馬力などの属性があり、コンピューターにはCPU、RAM、マザーボードモデルなどの属性があります。

これらはすべてリストであるため、さまざまなカテゴリ（COMPUTERS、CARS、CAMERAS）ごとに親LISTINGSテーブルと異なる子テーブルを作成する多態的なアプローチを考えていました。各子テーブルには、LISTINGSTABLEにリンクするlisting_idがあります。したがって、リストがフェッチされると、関連付けられた子テーブルのリンクされた行によって結合されたLISTINGSから行がフェッチされます。

LISTINGS
-listing_id
-user_id
-email_address
-date_created
-description

CARS
-car_id
-listing_id
-make
-model
-num_doors
-horsepower

COMPUTERS
-computer_id
-listing_id
-cpu
-ram
-motherboard_model

さて、このスキーマは優れたデザインパターンですか、それともこれを行うためのより良い方法がありますか？

私は単一の継承を検討しましたが、テーブルがすぐに大きくなりすぎるため、すぐに考えを一掃しましたが、別のジレンマが思い浮かびました-ユーザーがすべてのリストでグローバル検索を行う場合、それは各子にクエリを実行する必要があることを意味します個別にテーブル。100を超えるカテゴリがある場合はどうなりますか？非効率的ではないでしょうか。

また、各カテゴリのフィールドを定義するマスターテーブル（メタテーブル）と各リストのフィールド値を格納するフィールドテーブルがある別のアプローチを考えましたが、それはデータベースの正規化に反しますか？

Kijijiのようなサイトはどのようにそれを行いますか？

4

2 に答える 2

2

データベースの設計は問題ありません。あなたが持っているものを変える理由はありません。検索がいくつかの方法で行われるのを見てきました。1つは、検索ストアドプロシージャで、検索する必要のあるすべてのテーブルを結合し、検索する列にインデックスを付けることです。私が見た2番目の方法は、検索にのみ使用されるテーブルを作成して、検索する必要のあるフィールドのコピーを取得することでした。次に、これらのフィールドにトリガーを設定し、検索テーブルを更新します。

どちらにも欠点がありますが、私は最初のものを2番目のものよりも好みました。

編集

次のテーブルが必要です。

カテゴリ-ID-説明

CategoryListingsXref-CategoryId-ListingId

この相互参照モデルを使用すると、検索中に特定のカテゴリのすべてのリストに参加できます。次に、少し動的なSQLを追加し（理解しやすいため）、クエリを作成して、検索するフィールドを含め、クエリに対してexecuteを呼び出します。

それでおしまい。

編集2これは、これらのコメントボックスで確認できる少し大きな議論のようです。しかし、私たちが議論することはすべて、次の投稿を読むことで理解できます。 http://www.sommarskog.se/dyn-search-2008.html

それは本当に完全であり、賛否両論でそれを行うための複数の方法を示しています。幸運を。

于 2010-12-09T20:28:39.417 に答える
0

選択したデザインは、今説明したシナリオに適していると思います。サブクラステーブルに独自のIDが必要かどうかはわかりませんが。CARはリストであるため、値が同じ「ドメイン」からのものであることは理にかなっています。

典型的な求人広告サイトでは、広告のデータは一度書き込まれ、その後基本的に読み取り専用になります。これを利用して、ユーザーが検索したい方法で検索できるように最適化された2番目のテーブルセットにデータを保存できます。また、検索の問題は「一般的な」検索に対してのみ実際に存在します。ユーザーが特定のタイプの広告を選択すると、サブクラステーブルに切り替えて、より高度な検索を実行できます（RAM> 4gb、cpu = overpowered）。

于 2010-12-09T20:48:48.327 に答える