この注文状況のデータベーステーブルを設定するには

Question

印刷会社のWebアプリケーションを構築していて、自分のデータベースに最適なデザインを決定しようとしています。

私はordersテーブルを持っています。各orderには多くの証明があります。しかし、電子証明と物理証明の2種類の証明があります。さらに、電子証拠であれば、イメージソースを保管する必要があります。その証拠があれば、追跡番号を保管する必要があります。

すべての証拠には、多くのコメントが関連付けられています。

proofsテーブルと1つのcommentsテーブルを持つことができればいいですが、プルーフタイプに基づいてイメージソースとトラッキング番号を追跡する最良の方法は何ですか？

私はelectronic_proofsとphysical_proofsのための別々のテーブルを作成すると考えられてきたが、それは別のelectronic_proof_commentsテーブルとphysical_proof_commentsテーブルを作る必要であろう。

もう1つのオプションは、proofsという単一のテーブルを持つことです。この場合、単一のcommentsテーブルを持つことができます。しかし、それを見ると、それは3つのサポートテーブルproof_types,image_sources、およびtracking_numbersを必要とします。

この問題を解決する最善の方法についてのご意見はありますか？

Answer 1

別の回答に記載されているとおり、テーブルは1つだけ必要で、タイプに応じてフィールドの1つを空白のままにしておくだけです。しかし、私の答えの違いは、注文の詳細（または例の注文項目）の証明ではなく、注文の詳細を証明に関連付けることです。このようにすると、注文明細ごとに複数の校正を行うことができます。

これは、私はあなたがいた場合、私はそれを設定する方法を示します。

ORDERS

• 受注コード（PK）
• 得意先（FK）
• 等...

ORDERDETAILS

• OrderDetailsID（PK）
• 受注コード（FK）
• のProductID？ （FK）
• 等...

証明

• ProofID（PK）
• OrderDetailsID（FK）
• ProofType
• のImagePath（単にパスではなく、画像）
• トラッキング番号
• その他...

コメント

• CommentID（PK）
• ProofID（FK）
• コメント
• 等...

おそらくまたProofTypeを破るために賢明だろうそれ自体のテーブルには、しかし、仕事なしで動作します。これを行う場合は、ProofTypeテーブルを作成し、新しい "ProofType"テーブルの "ProofTypeID"フィールドを参照する外部キーに "Proofs"テーブルの "ProofType"フィールドを変更します。

希望すると便利です。がんばろう！

Answer 2

校正タイプはアイテムの属性に過ぎないと思いますが、追跡番号と画像ソースは正しいですか？

いくつかのアイテムがサイズになる可能性がありますが、そのアイテムの種類に関係のない属性は設定しないでください。

また、2つの異なる「証明」テーブルを使用すると、オーダー明細テーブルで2つの異なるエンティティを処理する必要があります。このような

何かが基本的な使用のためになんとかする必要があります...

ORDERS 
Order ID (PK) 

ORDER ITEM 
Order Item ID (PK) 
Order ID (FK) 
Proof ID (FK) 

PROOF 
Proof ID (PK) 
Proof Name 
Proof Type 
Tracking Number 
Image Source 

COMMENTS 
Comment ID (PK) 
Proof ID (FK) 
Comment Text 

必要に応じて証拠のタイプ、追跡番号、およびイメージソースのルックアップテーブルを作成することができます。現実をリレーショナル理論とどのようにマッチさせたいと思っていますか？

Answer 3

@Ricketts（+1）に同意します。トリッキーな部分は、校正テーブルに列ImagePathとTrackingNumberを持つかどうか、またはそれらを別々のテーブルに正規化するかどうかです。 （正規化は、主キーに依存しないため、主キー+プルーフタイプの列に依存します。）これらがプルーフタイプ固有の唯一の2つの列である場合は、、おそらくです。それらを単一のテーブルに格納しています...しかし、ImagePathは私を緊張させます。特にイメージではなく、実際にはかなりの大きさのバイナリデータの場合です。そのデータを独自のテーブルに個別に格納する理由はいくつかありますが、TrackingNumberも移動しないことは理にかなっています。

その他の考慮事項：プルーフタイプの比はどのくらいですか？パフォーマンスがどのように機能するか（特にデータ要求にBLOBが含まれている場合は特にそうです）最終的な決定を下す前に、これらの考慮事項を体重測定し、おそらくテストする必要があります。