-1

私は新しいウェブサイトを構築しています.3つの異なるタイプの製品があり、それらはいくつかのデータを共有し、それぞれが独自のデータを持っているという考えですproduct.共有データ用のテーブルを作成し、3つのテーブルを作成することを考えていました.各タイプの特定のデータについて。JOINしかしすぐに、親テーブルと 3 つの子テーブルの間で何もしないと、製品をロードできないことがわかりました。このソリューションを使用する必要があるのか​​ 、3つのテーブルを作成してそれらの間で共有列を複製する必要があるのか​​ わかりません。

各アプローチの長所と短所は何ですか?

どちらに従うべきですか？

4

2 に答える 2

2

簡単な答えは、「何をしたいかによる」です。
さまざまなシナリオで各アプローチを使用する場合の利点と欠点を次に示します。

製品テーブルと製品タイプごとに 3 つのサブテーブル

利点

  1. 型に関連しないクエリが多数ある場合は、これが間違いなく勝者です。たとえば、タイプに関係なくすべての製品が表示される「カテゴリ」リストがある場合、これは単純なクエリです。結合はなく、すべてがクールです。
  2. 1 つのテーブルにあるすべての製品は、将来のカスタマイズに適しています。別の製品タイプを追加する場合は、データを含む別のテーブルが必要です
  3. 重複データはありません。どこにもない。

短所

  1. このアプローチの唯一の本当の欠点は、実際には製品です。つまり、製品タイプごとに余分なデータが必要ない場合は、はるかに簡単になります. したがって、使用する必要がありますJOIN。しかし、それについて本当に悪いことは何もありません。

3 つの製品テーブル、それぞれが異なる製品タイプに対応

利点

  1. 製品タイプごとにデータを常に表示する場合、このアプローチには明らかな利点があります。つまり、データベース製品がピザ、コンピューター、およびペットである場合、3 つの製品タイプすべてに対してクエリを実行することは決してない可能性があります。その場合は、このアプローチを考えてみてください。
  2. 型内のより簡単なクエリ。

短所

  1. すべての製品をカテゴリ ビューで表示する必要がある場合は、これに対していくつかの深刻なUNIONクエリを実行する必要があります。それは、 を選択するよりもはるかに悪いことJOINです。
  2. nn製品タイプの表。
  3. 列が重複している可能性があります。悪いこと。

PS: 上記は、特定のニーズを考慮していません。これは、クエリのパフォーマンスを考慮しない、一般的な条件での一般的な提案です。
ただし、データが妥当なサイズである場合は、2 つのアプローチのいずれについても心配する必要はありません (最初のアプローチが明らかに有利です)。

于 2013-10-08T08:14:41.193 に答える
1

JOINリレーショナル データベースの不可欠な部分です。それが「悪い」可能性がある唯一の方法は、クエリで繰り返し作成する必要があるという小さな面倒なことです。JOIN重複データを排除するのに非常に役立ちます

于 2013-10-08T08:06:49.500 に答える