8

同じ列を持ち、テーブル名が異なるだけの 2 つのテーブル (リンゴとオレンジ) があるとします。これを 1 つのテーブル (Fruit と呼びます) に変換し、Apple または Orange の値を格納する「タイプ」列を追加することには、利点と欠点がありますか?

明確にするために編集します。

CREATE TABLE りんご ( id int, weight int, 品種 varchar(255) )

CREATE TABLE オレンジ (id int、weight int、variant varchar(255) )

また

CREATE TABLE 果物 ( id int, weight int, 品種 varchar(255), type ENUM('apple', 'orange') )

4

3 に答える 3

6

制約によって異なります:

  • apples存在しない外部キーまたは CHECK がありますかoranges(またはその逆)?
  • 両方のテーブルでキーを一意に保つ必要がありますか (そのため、 noappleは some と同じ ID を持つことができませんorange)?

これら 2 つの質問に対する答えが"yes"と"no"の場合は、テーブルを分離したままにします (したがって、制約をテーブル固有にすることができます1 )。

答えが"いいえ"と"はい"の場合は、それらをマージします (両方にまたがるキーを作成できます)。

答えが"yes"と"yes"の場合は、継承のエミュレートを検討してください2 :

ここに画像の説明を入力

1 ルックアップ データは、似ているように見えるテーブルの典型的な例ですが、FK を別々に保持できるように別々に保持する必要があります。

2具体的には、これは継承を表すための「すべてのクラスを別々のテーブルに」という戦略です (別名、カテゴリ、サブクラス化、サブタイプ化、汎化階層など)。詳細については、この投稿をご覧ください。

于 2012-08-30T17:16:28.990 に答える
2

If there really is not any further business rules (and resultant underlying data requirements) that separate the two sub-types then I would use one table with an fk to a FruitType lookup table.

You dont mention what you will be using to access the schema which may affect which approach you take (e.g. if you are using a platform which provides an ORM to your database then this may be worth noting).

于 2012-08-30T15:38:29.490 に答える
1

利点は正規化です。その場合、テーブルは2NF（第2正規形）になります。あなたの果物typeは、次のような果物と一緒にテーブルへの外部キーになります。

CREATE TABLE fruit_type (type varchar(15))

CREATE TABLE fruits (id int, weight int, variety varchar(255), type varchar(15))
于 2012-08-30T15:40:41.437 に答える