簡単な質問です。郵便番号アドレスを正規化する必要がありますか？
は、次の表（UK）を考えます
アドレスを別のテーブルに分割しますか？ 基本的なビジネスの前提は、顧客が複数の住所を持つことができないことです。
もともと私はこのような何かを見て、これをオフに区切ら：
カスタマー表
アドレス表
郵便番号表：
市表
私は郵便番号が一意streetnameや都市を識別することを間違った私の仮定を持っていない限り3NFでこれではないでしょうか？
基本的なビジネスの前提は、顧客が 以上の住所を持つことができないということです。
これが実際のルールであり、前提ではない場合、私はただ1つのテーブルにそれらを保持しています。
しかし、 'u'と 'me'に 'ass'を入れたとします。
安全にプレイし、別のテーブルにアドレスを入れてください。 しかし、それはあなたのサンプルからあまりにも多くの正規化を行っているようです。
これはすべてあなたの要件に依存しますが、上記のように顧客は複数の住所を持つことはできませんので、同じ関係に置くことができるため、別の1対1の関係は必要ありません。
しかし、私の経験によれば、今後の要件のために、それを別の1対多の関係に分割することをお勧めします。
はい、私は別のテーブルにアドレスを分割します。
しかし、その理由は正規化ではありませんそれ自体が（ほとんどの場合）です。主な理由は、それがゆっくりと変化する次元であり、以前のアドレスを調べることが有用な場合があります。
郵便番号のようなものを正規化するかどうかは、味わいの問題です。より「アマチュア」なデータベースでは、私はそれが必要とは思わない。しかし、実際の顧客の大きなデータベースの場合、私はそれを分割する傾向があります。郵便番号が正確であることを確認するのに役立ちます。また、時間とともに変化します。また、たとえば郵便番号レベルで追加情報を購入している可能性もあります。
個人的には、私は別のテーブルにアドレスを入れ、一緒にリンクします。
ビジネス仮説/ルールが変更される場合があります。これらの事項を分割すると、大きな再実行なしに可能なビジネスルールに対応できる可能性が高くなります。例えば
- おっと、顧客が配送先住所と異なる請求先住所を持っている、またはおっと、私たちは何かが実際に顧客が、今年のために自分のアドレスを変更していても、昨年出荷場所を知る必要がある、など
コメントありがとうございます、私の次の質問thoかどうか：ハウスナンバー、通り名と都市は郵便番号に依存しています。なぜなら、IDは3NFになるために別のテーブルに入れなければならないからです – satkin859
MySQLとMS-Access？関与していない製品にはタグを付けないでください。 – jarlh
これはどの国ですか？少なくとも米国では、この郵便番号は通りや必然的に都市を示すものではありません。私は他の国のことを確信することはできません。 –
こんにちは、これは英国です。 – satkin859