2011-01-12 12 views
1

私は、ノードのテーブル(権限に関連付けられたナビゲーションポイント)を保持する一般的なコンテンツ管理システムと、各種類のノード(ブログの投稿、コメント、添付ファイルなど)のテーブルを持っているとします。 (MySQLで)いつSQLテーブルに独自の数値プライマリキーを与える必要がありますか?

マイノードテーブルはそうのように見える:私は、一般的な権限を開発することができます

この方法を使用する
CREATE TABLE attachments (
    node_id INT PRIMARY KEY, 
    attachment_filename VARCHAR(255), 
    attachment_title VARCHAR(255), 

    FOREIGN KEY (node_id) REFERENCES nodes (node_id) 
) ENGINE = InnoDB; 
INSERT INTO node_types (type_name) VALUES ('attachment'); 

CREATE TABLE node_types (
    type_id INT PRIMARY KEY AUTO_INCREMENT, 
    type_parent INT, 
    type_name VARCHAR(31) UNIQUE KEY, 

    FOREIGN KEY (type_parent) REFERENCES node_types(type_id) 
) ENGINE = InnoDB; 

CREATE TABLE nodes (
    node_id INT PRIMARY KEY AUTO_INCREMENT, 
    type_id INT, 
    parent_id INT, 

    FOREIGN KEY (type_id) REFERENCES node_types (type_id), 
    FOREIGN KEY (parent_id) REFERENCES nodes (node_id) 
) ENGINE = InnoDB; 

そして、異なるタイプのノードを作成するために、私のような何かをnode_idを参照することで、すべての異なるノードタイプに特化する必要なく、ノードに適用されるシステムです。

この状況では、添付ファイルがノードと1対1の関係にあるノードであり、その主キーはnode_idに基づいているため、添付ファイルに「独自の」数字の主キーは与えませんでした。しかし、一部の人々は/行うだろう。添付ファイルテーブルを簡単にように書き換えることができます

CREATE TABLE attachments (
    attachment_id INT PRIMARY KEY, 
    node_id INT UNIQUE NOT NULL, -- a node is-a attachment. 
    attachment_filename VARCHAR(255), 
    attachment_title VARCHAR(255) 

    FOREIGN KEY (node_id) REFERENCES nodes (node_id) 
) ENGINE = InnoDB; 
INSERT INTO node_types (type_name) VALUES ('attachment'); 

あなたが重要な理由はなぜか、なぜ1がテーブルに数値の一意の主キーIDを与えて置くではないと思いますか?特に、私は、「1 :! is-a relationshipを持つテーブルにプライマリキーを割り当てない」というビジネスに時には矛盾していると感じています。

答えて

0

子テーブル(つまり、テーブルを指す外部キーを持つテーブル)を使用している場合は、親テーブルに主キーを作成する可能性が最も高いでしょう。

「リーフテーブル」がある場合は、実際には必要ありません。しかし、まだそれを持っていることは良い習慣かもしれません。 Webサイトやリーフテーブルのレコードへのリンクを含むブックマークを作成しているユーザのためにアクセスしたい場合は、ここにプライマリキーを追加することをお勧めします。

つまり、それは本当に依存しています。

+0

なぜそれは良い練習、btwだろうか?添付ファイルに主キーを作成すると、それに利点はありますか? – user572491

+0

@ user572491:そういうわけで、私は「それは良い習慣かもしれない」と言いました。あなたが話した相手と好きな人によって異なります。 - 利点について:あなたのロジックのいずれかでその列が必要ない場合、利点はありませんが、実際にはわずかにスペースを消費します。しかし、ある時点で、そのようなIDを必要とする追加のロジックを追加する必要がある場合は、すでにそれを持っているか、それに応じてテーブル構造を更新する必要があります。私が言ったように、それは本当に依存しています。 – sjngm

0

これは常に1:1の関係になっていれば、あなたのやり方はうまくいくはずです。

添付ファイルに異なるuniqe idを使用することは何の理由もないはずです。

0

現在お持ちのままにしておきます。余分な数字のIDを導入することは、混乱のレシピのように思えます。あなたが添付ファイル11375を探しているのなら、そのattachment_idまたはそのnode_idは?

一般的なアドバイスとして、どのテーブルでも最大で1つのサロゲートキーが宣言され、実際に存在する多くの実際のキーがあることをお勧めします。サロゲートキーは、varchar列や(正確な状況によるが)キーのように、実際のキーのどれもがインデックス、FK参照などに含めるのに適していないときに使用される数字キー(例えばint)である。複数の列。

+0

添付ファイルのnode_idはサロゲートキーとしてカウントされますか? – user572491

+0

@ user572491 - 私はそう言っています - それはサロゲートです(実際には現実世界に関係しないので)(テーブル内の特定の行を一意に識別するために使用できるので) –

関連する問題