4

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

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に同様のソリューションがあることを期待していたテーブル間でシーケンスを共有できました。回答に基づくものではないと思います。私はテーブルの継承に行かなければならないと思います...ありがとうございました。

4

7 に答える 7

9

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

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つのマスター製品テーブルと、タイプ固有のデータを持つマスター製品テーブルへの外部キーを持つタイプ指定テーブルがあります。

于 2011-01-25T17:08:18.670 に答える
5

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

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

また、デザインでは、各製品を最大で1つのカテゴリに分類できることにも注意してください。

于 2011-01-25T17:11:36.290 に答える
1

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

product1productとproduct2の両方に共通のtype属性に加えて、"product2"または"product1"

次に、テーブルproduct1product2は、すべての特定の属性とテーブルへの参照を持ちますproduct

product:
    id,
    name,
    category,
    type

product1_table:
    id,
    #product_id,
    product1_specific_fields

product2_table:
    id,
    #product_id,
    product2_specific_fields
于 2011-01-25T17:12:11.167 に答える
1

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

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

共有PKには2つの理由があります。2つのテーブルにまたがる1つの一意性と、参照整合性を完全にするための2つの一意性。

Auto_increment列がサポートする「シーケンス」機能が正確にわかりません。値による増分を定義するシステム設定があるようですが、列ごとには何もありません。

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

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

これは行ごとのトリガーである必要があり、これらのテーブルのクラッドの速度が低下することに注意してください。しかし、「product」のようなテーブルは、そもそもDMLの割合がそれほど高くない傾向があります。「パフォーマンスへの影響」について不満を言う人は、規模を考慮していません。

これは機能する代替手段として提供されており、最善の方法としての私の推奨ではないことに注意してください

于 2011-01-25T17:41:48.730 に答える
0

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

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

もう1つのオプションは、ある種の継承モデルを使用することです。このモデルでは、単一の製品テーブルと、メインの製品テーブルを参照し、独自の特殊なフィールドセットを持つ2つの製品「サブタイプ」テーブルがあります。このモデルのクエリは、単一のテーブルIMHOよりも面倒です。そのため、このモデルはあまり望ましくないオプションだと思います。

于 2011-01-25T17:11:11.143 に答える
0

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

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

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

product_extra1テーブルとproduct_extra2テーブルには、異なるフィールドが含まれています。これらのテーブルには、product.product_idとproduct_extra1.product_idなどの間に1対1の関係が適用されます。外部キーテーブル(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)があります。これは、各製品が多くのカテゴリに関連付けられることを意味します。これは同じままです。

于 2011-01-25T17:16:43.703 に答える
0

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

前の説明を参照してください

于 2011-01-25T17:58:47.153 に答える