2016-08-10 6 views
0

データベース設計上の入力が必要です。私は忙しいです。異なる表の列に対する複数列の一意性制約

私がモデル化しようとしていることを要約すると(database diagramを参照してください)。

オプション1:

  • Fileのエントリは、それに適用された1つの以上の原価要素を有していてもよいです。
  • コスト要素には、説明、メジャー(通貨または%)、配分(質量、容積など)および値(数値)があります。
  • 複数列の一意性は、FileIDCostDescriptionIDの組み合わせで適用する必要があります。
  • プロ:上記の要件でデータの整合性を強制する一意のインデックスを作成できます。
  • コン:原価要素の組み合わせは再利用することができません - データの複製。

オプション2:

  • エントリの重複を減らすために、CostElement2は、3つのテーブルに分割されている:CostDefaultCostInputCostElement
  • プロ:CostInputでは、CostDescriptionID,CostMeasureIDおよびCostAllocationIDの組み合わせを再利用できます。
  • proCostInputは、CostElementIDElementValueの組み合わせの再利用が可能です。
  • ConFileIDCostDescriptionIDの組み合わせで複数列の一意性制約を適用することはできません。

私は両方の世界のベストを得ることができるより良い設計決定がありますか?

ご協力いただければ幸いです。

多くの感謝!

+0

なぜ、すべての単一のテーブルにGw_プレフィックスを追加していますか?おそらく、スキーマは良いでしょうか?私は個人的にこのような接頭辞を嫌う。彼らは無意味な入力を加え、何も追加しない。また、テーブル名を読むのが難しくなります。なぜあなたの列名の大部分の中央にGWがありますか?私はIdGwCostDefaultの代わりにCostDefaultIDのようなことをします。そして、すべてのコスト(タイムスタンプ、値、名前、説明など...)で列名の予約語を避けるべきです。手元の問題については...まあ、私はあなたが何を求めているのか本当に理解していません。 –

+0

こんにちはショーン、私の質問に答える時間をとってくれてありがとう。投稿する前に質問を読んだとき、私は自分自身に "嘔吐する"と思った。あなたの提案された命名の変更を取ってきました。 Gw_接頭辞の理由は、これらのテーブルを既存のERPデータベースに追加するためで、ERPが推奨するカスタムテーブルの追加ガイドラインは、特定の文字列を接頭辞として使用するためです。また、データベース内のテーブルをグループ化するのに役立ちます。私はその質問に言い換えようとしましたが、今私が求めていることがはっきりしていることを願っています。あなたがコメントするほど親切であれば。ありがとう。 –

+0

私はそのドキュメントを無視します。それは素晴らしい提案ではありません。新しいスキーマを作成する奇妙な接頭辞の代わりにはるかに良いでしょう。それはオブジェクトエクスプローラでアイテムのようにグループ化しますが、あなたは不条理な名前に取り組む必要はありません。私は本当にあなたの質問を完全に理解していませんが、オプション2はあなたが望むものに近いように聞こえます。オプション1は、多くの痛みを引き起こす非正規化されたデザインのようです。 –

答えて

0

私はオプション1、単一のテーブルを堅持することをお勧めします。この場合、列の組み合わせは、さらなる正規化を必要とする再利用ではありません。

FileIDCostElementIDの順に複合主キーを作成するだけで簡単に作成できます。

名前付けに関する私の唯一のコメントは、名前が「File」のテーブルでは不快です。それ以外は、あなたは大丈夫です。

関連する問題