SQL結合/接合テーブルに追加のデータを格納する必要がありますか？

Question

追加/結合テーブルに追加データを格納する際に欠点がありますか？例えば、私はトラック運送会社のデータベースに取り組んでいると私は3つのテーブルを持っている

：

は

Table 1 - company, 
Table 2 - trailer_type, 
Table 3 - junction_table, 

各企業は、複数のトレーラータイプを持つことができますが、私はまた、各トレーラータイプのトレーラー回数を必要とします会社ごとにトレーラー数を配置する最も論理的な場所は、company.idとtrailer_type.idを持つジャンクションテーブルにあるようです。

このようにすることには何らかの欠点がありますか？その場合、より良い方法がありますか？

Answer 1

あなたの質問を表現する方法から、私はあなたの直感が大抵正しいと思います。ジャンクション・テーブルをあなたのカウントを保持する場所として指定しました。しかし、あなたは「ジャンクション・テーブル」なので、躊躇しています。

すべてのテーブルは同じに作成されます。 SQLの観点からは、ファクト表、ディメンション表、ジャンクション表はありません。テーブルのみがあります。

正規化されたデザインは、各行を識別する最小のキーを示します。あなたの場合、ジャンクションテーブルのナチュラルキーは{company_id、trailer_type_id}のようなものです。機能的にそのキーに依存する情報はありますか？なぜ、はい、ある：ntrailers。したがって、列が生まれます。

それで、どのような種類の表であるか心配しないでください。行番号はを意味し、どのように識別されているのかを考えてください。それはあなたをフェアウェイにつないでくれるでしょう。

Answer 2

まず、追加情報をジャンクションテーブルに格納しても問題ありません。たとえば、作成された日付は非常に興味深いことがよくあります。ジャンクション・テーブルと考えることができるエンティティの多くの例があります。たとえば、顧客と請求書を結びつける請求レコードです。レコードには当然追加フィールドがあります。

しかし、この数は通常の状況で保存するものではありません。このタイプの情報は、特に時間が経つにつれて修正される場合はCompanyテーブルに格納されます。

固定されていない場合は、2つの選択肢があります。最初のものはゆっくりと変化するディメンションで、企業の予告編の数とその有効期限と終了日を保存します。実行可能な代替方法は、ジャンクション・テーブルに値を格納することです。これは最初の選択ではありませんが、多くの状況では良い解決策になるかもしれません。

Answer 3

スキーマは、企業と予告編の多対多の関係とは少し違っていると思うかもしれません。それがジャンクション・テーブルを持つ理由です。どのようにそれの考え方について、このよう

：

1. 企業はトレーラー
2. トレーラーと1対多の関係を持っているがTrailerDescriptionsと多対1の関係を持っています。

だから、あなたのトレーラーのテーブルには、これらの列を持つことになります。

company_id 
trailer_description_id 
count 
etc. 

あなたも、列を追加し、1

trailer_id 
company_id 
trailer_description_id 
count = 1 
date_placed_in_service 
license_plate_number 

に「カウント」を設定することで、個々のトレーラーを列挙することを選択するかもしれません

など