私の問題はDBスキーマの開発に関連しており、次のとおりです。
アイテムやサービスの購入に使用したい購入モジュールを開発しています。以下は私のEER図です（サービスには特殊な属性がほとんどないことに注意してください–最大2）
私の問題は、製品とサービスを2つのテーブルに保持することですか、それとも1つのテーブルに保持することですか。
1つのテーブルオプション–製品かサービスかを識別するための「item_type」フィールドを持つアイテムテーブルを参照するアイテムIDを指定するだけでよいため、複雑さが軽減されます
2つのテーブルオプション–参照したいすべての場所で個別の製品またはサービスを参照する必要があり、製品またはサービスのいずれかを参照するすべてのテーブルで「item_type」フィールドを保持する必要がありますか？
現在、オプション1の使用を計画していますが、この問題に関する専門家の意見を知りたいです。あなたの時間とアドバイスに大いに感謝します。ありがとう。
私は確かに「2つのテーブル」オプションに行きます。ご覧のとおり、製品とサービスを区別する必要があるためswitch(item_type) { ... }、プログラムで使用するか、製品とサービスで完全に異なるコード パスを使用できます。また、DB スキーマを更新する必要が生じた場合、switch維持するのが難しくなります。
2 つ目の理由は NULL です。できる限り避けることをお勧めします — それらは解決するよりも多くの問題を生み出します. 2 つのテーブルを使用すると、すべてのフィールドを非 NULL と宣言でき、NULL 処理を忘れることができます。1 つのテーブル オプションでは、コードを手動で記述して、 の場合item_type=product、製品固有のフィールドが NULL ではなく、サービス固有のフィールドが NULL であること、および の場合item_type=service、サービス固有のフィールドが NULL でないこと、および製品固有のフィールドが NULL であることを確認する必要があります。それは。これはあまり楽しい作業ではなく、DBMS ではそれを行うことはできません ( NOT NULL IF another_field = valueSQL などには列の制約はありません)。
2つのテーブルで行きます。サポートしやすくなります。私はかつて、すべてのデータがたった 2 つのテーブルに格納されている DB を見たことがあります。必要なフィールドが NULL でないことを確認するためのページとコードのページがありました。
実装するなら、Two table オプションを選択したでしょう。これは、スキーマの正規化の最初のルールのようなものです。多値属性を削除するには。item_type の使用はお勧めしません。別のテーブルを作成すると、item_type を使用する必要がなくなり、外部キー関係を使用することができます。
この記事を読むことを検討してください: http://en.wikipedia.org/wiki/Database_normalization
それは役立つはずです。