質問

これはかなり一般的な質問だと思いますが、過去の質問のリストには見つかりません。主キーインデックスを共有する必要がある製品用のテーブルのセットがあります。次のようなことを想定します。

product1_table:
    id,
    name,
    category,
    ...other fields

product2_table:
    id,
    name,
    category,
    ...other fields

product_to_category_table:
    product_id,
    category_id

2 つの製品テーブル間に共有インデックスがあると便利であることは明らかです。これらを分離するという考えは、これらのフィールドには基本以外のフィールドのセットが大きく異なりますが、共通の分類を共有しているためです。

アップデート：

多くの人がテーブル継承 (または gen-spec) を提案しています。これは私が知っているオプションですが、他のデータベース システムではテーブル間でシーケンスを共有できるため、MySQL にも同様のソリューションがあることを期待していました。回答に基づいてそうではないと仮定します。テーブル継承を使用する必要があると思います...皆さん、ありがとうございました。

役に立ちましたか？

解決

それは本当に一般的ではありません、いいえ。主キーを共有するネイティブの方法はありません。あなたの状況で私がするかもしれないことはこれです：

product_table
    id
    name
    category
    general_fields...

product_type1_table:
    id
    product_id
    product_type1_fields...

product_type2_table:
    id
    product_id
    product_type2_fields...

product_to_category_table:
    product_id
    category_id

つまり、すべての製品のエントリを備えたマスター製品テーブルが1つあり、タイプ間で一般化するフィールドがあり、タイプ固有のデータを持つマスター製品テーブルに外部キーを含むタイプ指定テーブルがあります。

他のヒント

より良いデザインは、共通の列を1つの製品テーブルに、特別な列を2つの別々のテーブルに配置することです。 Product_idを3つのテーブルすべての主キーとして使用しますが、2つの特別なテーブルでは、メイン製品テーブルに戻る外部キーです。

これにより、カテゴリごとにIDと名前の基本的な製品検索が簡素化されます。

また、設計により、各製品がせいぜい1つのカテゴリにあることに注意してください。

テーブルの継承を探しているようです。

一般的なテーブルを使用できます product Product1とProduct2の両方に共通の属性と type どちらかの可能性がある属性 "product2" また "product1"

次に、テーブル product1 と product2 すべての特定の属性とへの参照があります 親 テーブル product.

product:
    id,
    name,
    category,
    type

product1_table:
    id,
    #product_id,
    product1_specific_fields

product2_table:
    id,
    #product_id,
    product2_specific_fields

まず、カオス、ラリー、フィルが言ったすべてのことに同意していると述べさせてください。

しかし、あなたが別の方法を主張するなら...

共有PKには2つの理由があります。 2つのテーブルに1つのユニークさと2つのユニークさがあり、参照整合性を完了します。

どの「シーケンス」がAuto_increment列のサポートをサポートしているかは正確にはわかりません。あるように見えます システム設定 増分を値で定義しますが、列あたりは何も定義しません。

Oracleで私がやることは、2つのテーブル間で同じシーケンスを共有することです。別の手法は、auto_incrementで2のステップ値を設定し、1で1つ、もう1つは2で開始することです。どちらにしても、それらの間に一意の値を生成します。

PK列以外の何もない3番目のテーブルを作成できます。この列は、1つのサーバー内にスキップオートナンバーを作成する方法がない場合、自動剤を提供することもできます。次に、各データテーブルでCrudトリガーを追加します。いずれかのデータテーブルに挿入すると、最初に擬似インデックステーブルへの挿入が開始されます（そして、ローカルテーブルで使用するためにIDを返します）。同様に、ローカルテーブルからの削除は、擬似インデックステーブルから削除を開始します。親を指す必要がある子供のテーブルは、この擬似インデックステーブルを指します。

これは、1列あたりのトリガーである必要があり、これらのテーブルのCrudを遅くする必要があります。しかし、「製品」のようなテーブルは、そもそもDMLの割合が非常に高くない傾向があります。 「パフォーマンスの影響」について不平を言う人は誰でも いいえ スケールを検討します。

これは、機能する代替として提供されており、私の推奨ではありません。 一番 仕方

主キーを「共有」することはできません。

すべての詳細を知らずに、私の最善のアドバイスは、テーブルを単一の製品テーブルに組み合わせることです。一部の製品に入力され、他の製品ではないオプションのフィールドを持つことは、必ずしも悪いデザインではありません。

別のオプションは、単一の製品テーブルがある一種の継承モデルを持ち、次にメイン製品テーブルを参照し、独自の専門のフィールドセットを持つ2つの製品「サブタイプ」テーブルを持っていることです。このモデルを照会することは、単一のテーブルiMhoよりも痛みを伴うため、あまり望ましくないオプションと見なしています。

あなたの説明は少し曖昧ですが、私の基本的な理解から、私はこれをしたくなるでしょう

製品テーブルには共通フィールドが含まれています

product
-------
product_id
name
...

Product_extra1テーブルとproduct_extra2テーブルには、これらのテーブルが異なるフィールドを含みます。一意制約を使用して外部キー テーブル (product_extra1 など) の product_id を一意に設定することで、1 対 1 の関係を強制します。このデータをどのように入力するかについてのビジネス ルールを決定する必要があります。

product_extra1
---------------
product_id
extra_field1
extra_field2
....

product_extra2
---------------
product_id
different_extra_field1
different_extra_field2
....

Product_categoryテーブルの上にあるものに基づいて、交差するテーブル（1から多くの - 多くのものか​​ら1）があります。これは、各製品が多くのカテゴリに関連している可能性があることを意味します。

これは、Gen-Specのさらに別のケースです。

以前の議論を参照してください

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top