私の会社のデータベースの一部が将来のニーズを満たしていないため、再作成しています。 現在、私たちは主にフラットファイルと、決して完全に実現されなかったいくつかの分離されたテーブルを持っています。住所データベースを作成する
私の考え方では、おそらくzipsテーブル以外の各カテゴリのテーブルがあります。私は考えています一つはジップテーブルを削除し、郵便番号は、ほぼ一意であるので、ちょうどzipstocitiesテーブルに郵便番号を入れて、その後にテーブルをインデックスされ
Database Diagram http://www.freeimagehosting.net/uploads/248cc7e884.jpg
： 下の画像を参考にしてください郵便番号。唯一の欠点は、郵便番号が先行ゼロの郵便番号の世話をするためにはvarcharでなければならないことです。私の論理に欠陥があるかどうかを知りたいだけです。
私は米国の郵便番号と領土のデビエーションシステムはよくわかりませんが、私はそれがドイツのものとやや似ていると思います。
したがって、次のスキーマを使用します。
ZipCodes CityZipCodes
------------ ---------------- Cities
ZipCode (PK) <─── ZipCode (PK)(FK) -----------
City (PK)(FK) ───> CityId (PK)
Name
County (FK) ───┐
│
│
Counties │
------------- │
States CountyId (PK) <───┘
----------------- Name
StateId (PK) <─── State (FK)
Name
Abbreviation
郵便番号ごとに複数の都市で修正されました。
時折、ジップに複数の都市があります – Sean
郵便番号ごとに複数の都市が修正されました。 –
一般的にはい、しかし時には郵便番号が1つの都市と郵便番号の間で共有される場合があります。また、いくつかの都市では - 94303が1つあり、都市は2つの別々の郡に分かれています。私の住所はSanta Clara郡のPalo Alto、CA 94303にあります。 94303はサンマテオ郡にあるイーストパロアルト（？の一部）もカバーしています。私の住所をWebフォームに入力するとき、私は定期的に自分の郵便番号がどこにあるかを選択する必要があります。 –
あなたが持っているダイアグラムを見ると、本当に必要な4つの外部テーブルのうちの1つしか状態テーブルではありません。 IDと単一の値を持つルックアップテーブルは努力する価値がありません。これらの関係は、メインテーブル（ziptocities）内の単一の値をルックアップテーブル（状態）内の関連データのセットと呼ぶように設計されています。
はい、しかし都市はseverl郵便番号と郡にはいくつかの都市がある場合もあります。また時にはジップには複数の都市があります – Sean
今回私は英語をもう一度試してみましょう：はい、都市にはいくつかの郵便番号があり、郡にもいくつかの都市があるかもしれません。時にはジップに複数の都市があることもあります – Sean
私はそれに同意します。しかし、ziptocityテーブルでは、zipを都市、郡、州にマッピングします。私の指摘は、単一の情報（郵便番号）のプレースホルダーであるzipIDを参照する場合、値と参照値を格納するのではなく、単にその単一の値を使用するだけではないということです。参照メソッドを使用すると、ziptocitiesの各行に1つのエントリを加え、zipの可能な値ごとに1つのエントリを使用します。単純に郵便番号を使用すると、各行には1つのエントリしか使用されません。これにより、DBのサイズと複雑さが排除されます。 – Mentee
注意すべき点は、すべての都市が郡にあるわけではないことです。バージニア州では、あなたは都市または郡のいずれかにいますが、どちらにもなりません。
あなたは郡を気にする理由を自分に尋ねる必要があります。米国の多くの州では、伝統や地図を超えた重要性はほとんどありません。
その他の質問は、住所が正確であることがどれほど重要なのでしょうか？重要な手紙がタイムリーに届かないと死亡者は何人になるでしょうか（手紙が処方箋薬のリコールに関するものであれば多くの場合可能性があります）
おそらく、郵便サービスのデータを、アドレスを修正します。そうすれば、あなたが良い住所を得たときに、郵便がそこに届けられることが確実になるでしょう。
会社の所有者はそれらを望んでいます... – Sean
それらを追加し、オプションにしてください。彼らがコンテナではないことを彼に思い出させてください。もし彼がそのように考えているなら、彼らはこの階層の一部ではありません。 –
プロセスとロジックの両方に欠陥があるようです。
私は、あなたがテーブルと人間関係について考えていることをしばらくは止めることをお勧めします。代わりに、事実を考えてみてください。データベースがサポートする必要がある有効なアドレスのリストを作成します。多くの驚きがあなたを待っています。
住所と郵送用ラベルを混同しないでください。彼らは全く同じことではありません。キャリアのモデリングも検討してください。米国では、住所が有効かどうかは運送業者によって異なります。たとえば、運送会社がUSPSである場合、私のPOボックスは有効なアドレスですが、運送業者がUPSである場合は無効です。
bitboostで国際的なアドレス形式を参照すると、時間を節約できます。
2つの国で同じ郵便番号が使用されていると、ロジックが機能しますか？この2つは、その場合、異なる都市を指しているでしょう。ここにいくつか考慮すべき点があります
。
これは米国以外の国では使用されません。これは米国の特定の医学上の主張および法律のために開発されたものです。 – Sean
国の詳細をドロップします。私はあなたが機能的な依存関係の知識を持っていると仮定しています。あなたは以下の機能的依存関係を持っています。 郵便番号 - >カウント、都市、州 ただし、デザインに次の機能依存関係はありますか？ - >州名 - >郵便番号 あなたのデザインは、理論的には非常に標準化されていないようです。ただし、クエリに結合が多すぎます。これがパフォーマンスに影響する可能性があります。 関数の依存関係 a-> bは、R1（a）= R2（a）の場合、R1（b）がR2（b）に等しくなければならないことを意味します。 – bkm
私は郡が無関係であることに同意しますが、会社の所有者は彼らが妥当であるように欲しいと考えています。以上、私は上記のDaniel Broucknerの実装を考えています。その論理を破る特殊なシナリオを探してみましょう。 – Sean
ではなく、持っているすべての人に有効な医療請求があります法律で米国に留まる必要があるクレームが解決されました。人々は動く。
私たちが真に患者を追跡しようとしていないのは、治療時に彼らが米国に居住していることを実証しているだけなので、その懸念事項は無関係です。 – Sean
サンフランシスコはカリフォルニア州の都市です。アラバマ州の都市ではありません。あなたのデザインは "サンフランシスコ、AL"のようなナンセンスのエントリを防ぐのですか？
はい郵便番号 – Sean
5桁のZIPは、2つの地名が同じZIPを使用し、1つのZIPが2つの都市名を参照できるため、適切なキーではありません。 http://semaphorecorp.com/cgi/zip5.html
このデータベースはどのようなものですか？このスキーマが過度に正規化されているので、私は言うでしょう。 – Lazarus
患者情報を追加するために使用されます 主なシナリオ：患者は郵便番号を知っています残りのすべてのフィールドは自動的に入力します 可能性のある他のシナリオ：患者は住んでいる都市と州のみを知っています。郵便番号と郡に自動入力されます – Sean
過標準化？私は完全に非正規化されたと思う。 –