アイテムのリストがあります。これらの商品のほとんどは在庫がありません。アイテムテーブルには、ID、名前、説明があります。アイテムの数量は、inventoryという名前の別のテーブルに保存されます。在庫テーブルには、item_idと在庫のあるアイテムの数量が含まれています。
インベントリテーブルの主キーは必要ですか？もしそうなら、私はシリアルまたは複合キーを使用する必要がありますか？テーブルに主キーがなくても大丈夫なのはいつですか。
編集：非常に有益であるためにすべてに感謝します。非常にまれな例外を除いて、私は常に主キーを持っています。また、シリアルキーとコンポジットキーについてもう少し学びました。
常に主キーを持つことを目指してください。
よくわからない場合は、主キーを用意してください。
あなたがそれを必要としないだろうと99.99％確信しているとしても、それを持ってください。長年の経験から学んだように、要件は変化します。
私が実際に考えることができる唯一の例は、2つのforeign_keysとすべてのバイトが重要なメガヒュージ（数億行）のテーブルを持つ多対多のテーブルです。ただし、それでも、個別の一意のビジネス価値のないIDキーを強くお勧めします。
これに関するいくつかの素晴らしい情報がここにあります：
http ：//weblogs.sqlteam.com/jeffs/archive/2007/08/23/composite_primary_keys.aspx
そしてここ：
http
：//www.techrepublic.com/article/the-great-primary-key-debate/1045050
ここ： http：
//databases.aspfaq.com/database/what-should-i-choose-for- my-primary-key.html
およびここ：
複合主キーを使用する必要がありますか？
あなたの例では、私は間違いなくそれを持っているでしょう。
「持っていない」という決定は、非常に明確な必要性と理解、および持っていることに関する実際のまたは予測された（たとえばボリューム）問題に基づいている必要があります。
この必要性の1つの優れた例は、デバッグおよびトラブルシューティング時に発生します。各テーブルに列を作成して更新するのと同じように（私のもう1つのお気に入り）、この情報は最初はフロントエンドで使用されない場合がありますが、問題の追跡と解決に役立ちます。（ところで、更新スタンプは、Ruby On Railsのようなフレームワークで標準になっていることが多く、フィールドを持つすべてのテーブルの規則でもうまく機能しidます！）
インベントリテーブルの主キーは必要ですか？
データがリレーショナルであると想定できますか？定義上、リレーションには重複するタプルはありません。SQLでは、テーブル内の行を重複させることができます。したがって、実際に重複行がないようにするには、すべてのテーブルに少なくとも1つの一意の制約が必要です。長い話を短くするために、テーブル内のすべての候補キーに一意の制約を設定しないのには十分な理由があります。定義上、0個または1個の候補キーを「プライマリ」と指定することができ、この指定を受け取る必要があるのはどれか（存在する場合）は任意です。
シリアルキーまたはコンポジットキーを使用する必要がありますか？
これはタイプミスだと思います。単一列のキーは、「シリアルキー」ではなく「シンプルキー」と呼ばれます。説明から、Inventoryテーブルにはに唯一の候補キーがありitem_ID which is a simple keyます。唯一可能な複合キーはスーパーキーであり、外部キーによって参照される場合を除いて、一意性制約を使用して制約されるべきではありません。
テーブルに主キーがなくても大丈夫なのはいつですか。
すべての候補キーが制約を使用してUNIQUE制約されている場合、またはテーブルがリレーショナルデータを保持することを目的としていない場合。
一般的に：すべてのテーブルにはPKが必要です。少なくともすべてのテーブルには、クラスターインデックスが必要です。PKは1つの特別な列であってはなりませんが、システム（RDBMS）で一意のIDのない行を持つことは適切な方法ではありません。
PKが不要な場合もありますが、それは例外です。
item_idが在庫テーブルで一意である場合、それを識別子として使用しても問題ないと思います。主キーは通常、ラインを一意に識別するために使用されますが、私が見ることができるあなたのケースでは、在庫ラインIDは使用されません。
編集：他の人が指摘しているように、一般的に主キーの正当な理由がない場合は、テーブル構造を調べて、別のテーブル（この場合はおそらくアイテム）とマージできるかどうかを確認することをお勧めしますテーブル。それがオプションではない場合（たとえば、スキーマを変更できない、新しいテーブルを追加するだけ）を見ることができますが、一見の価値があります。
アイテムごとに在庫行が1つしかない場合は、同じアイテムテーブルにあるよりもはるかに安価になります（つまり、CPUとIO）。
そうでない場合-それは異なります。そして、それは正規化されたデータではありません
しかし、私が質問を理解している限り、そしてあなたが2つのテーブルを主張するなら-はい、item_idフィールドにインデックスを持っている方が良いです