web-dev-qa-db-ja.com

Relational DataBaseに年表を追加してもよろしいですか？

これは不必要な複雑さと冗長なデータであることを同僚にどのように説明できますか？

多くのテーブルには「年」の値があるため、彼は年のテーブルを持ちたいと考えています。また、名前と年のリレーションテーブルも必要です。これにより、不要な内部結合が追加され、Foreign iはこれが間違っていると主張します。これが良い習慣ではないことを確認してください...

Database diagram picture

sql-servermysqldatabase-designtable
1
Chris

_vehicle_year_はデータ型YEARである必要があります。

日付はデータ型DATEである必要があります。日付を構成要素に分解する必要がある場合でも、ほとんどの場合、日付とその部分を含むディメンションテーブルを用意するよりも、そのように行う方が適切です。

一般に、not「連続」値を「正規化」します-日付、整数、浮動小数点数など。

Kevenskyが指摘したように、欠けている年（または何でも）に対してゼロを表示する必要がある「レポート」を別の方向に進めるためのユースケースがあります。しかし、これは何らかの方法でメインテーブルにリンクされているnotです。代わりに次のようなものを使用します

_SELECT y.year,
       COALESCE(SUM(m.stuff), 0),
       ...
    FROM Years AS y
    LEFT JOIN my_table AS m
    GROUP BY...
_

_LEFT JOIN_には、Yearsテーブルのすべての年がどのように含まれるかに注意してください。 （WHERE句で範囲を制限したい場合があります。）

そして、COALESCEは、不足している年のNULLを_0_に変換するために使用されます。または_N/A_。または_No data_。または何でも。

私がそれにいる間、私は「モデル」の正規化は「過剰正規化」でもあると提案します。 Vehicleテーブルでは、スペルアウトされたモデル名は完全に問題ありません。

すべきの場合、正規化しますか？

  • 一意ではない-人の名前。
  • 値が変更される可能性がある場合-車両の所有者（ただし、これには多くのテーブルが必要です）
  • 多くの補助データがあります-会社（住所など）
  • スペースを節約するために-名前は長く、テーブルは大きいです。 not 2文字の国コードと4バイトINTの場合。

モデル年は自己識別型であり、変更されることはなく、大きくはなく、補助データもありません。

車両のメーカーとモデルは、モデルの年式とほとんど同じです。エンジンのサイズ、色、価格などの同上。

「シボレーがImpalaモデルを作成したのは何年（model_years）ですか」という仮説のクエリに分岐しましょう。

「SELECT DISTINCT model_year FROM Vehicle WHERE make = ...;」で答えることができます。これは、テーブル内の利用可能なVehiclesから答えを取得します。

または、答えがリストされている歴史的なWebサイトから入手することもできます。ここで、PRIMARY KEY(make, model)を含むテーブルと、古い車の履歴に関するさまざまな情報が必要です。

それは厄介な状況につながります-階層情報。注：GM>シボレー>インパラ> LT。「場所」には同様の問題があります：米国>ジョージア州>フルトン郡>アトランタ>住所。一般に、各レベルでの正規化はひどい過剰であり、避けた。

多くのテーブルには「年」の値があるため

まあ、正規化のための「教科書」の議論はここで惨めに失敗します。値を1か所にまとめて変更しやすくするには、正規化する必要があると述べています。しかし、そのyearが1つのテーブルの車両のmodel_yearを表し、別のテーブルの子供の誕生日と別のテーブルの卒業を表す場合、値を変更したくないはずです。

正規化テーブルは、人、場所、会社、写真、Web投稿などの「エンティティ」と考えてください。エンティティに一意の識別子（_PRIMARY KEY_）を付けて、誰もが参照できるようにします簡単に。テーブルには、印刷可能な名前、場所、「いいね」のカウンターなどがあります。

2
Rick James

私は年の表を使用して、適切な数のフィルターを使用してその年の結果が得られなかった可能性がある場所を報告しました。クライアントは、たとえゼロであっても、その年の金額を表示したいと考えていました。年表を作成することにより、すべての人に価値があることを保証しました。代わりの方法は、より多くのスキャンを必要とすることでパフォーマンスを損なうと感じた外部結合を行うことでした。

ユースケースはさまざまかもしれませんが、それは常に悪い考えではありません

1
kevinsky

簡単に言えば、数値を使用して別の数値を関連付けていると思いますが、それだけです（現在のところ、追加の値はありませんyearsテーブル）。

次に、すでに述べたように、何年もクエリを実行するには追加の作業（結合、サブクエリなど）が必要になります。

0
watery