0

建物、人、車などのアドレスを保存する必要があるシステムを作成しているとします。

アドレスの「形式」は次のようになります。

州 (州リストから)
郡 (郡リストから)
番地 (「5 番街」などのフリー テキスト)
番号 (「クライスラー ビル、10 階、オフィス 10 番」のような自由なテキスト)

(はい、私はアメリカに住んでいません)

その情報を保存する最良の方法は次のとおりです。

  • 、Person_Address、Car_Address...
  • または、住所情報は各エンティティの列にある必要があります。
  • アドレス テーブルを 1 つだけ使用して、各行を別のエンティティにリンクすることはできますか?

または、このタイプのシナリオを処理する別の「より良い」方法はありますか?
どのようにしますか？

4

3 に答える 3

1

Address が Address テーブルに格納され、People からのアドレスへのリンクを格納する多対多のリンク テーブルがあるシナリオを見てきました。外部キーを強制できるように、それぞれに個別のテーブルがあります。リンク テーブルには、プライマリ、出荷先などの関係に関する情報が格納される場合があります。

また、住所が顧客の行に格納されている場所も見ました。これにより、請求先、発送先などの住所の効果的な配列が得られますが、それで問題ありません。両方を扱ったので、私はそれらを独自のエンティティに持つことを好むと思います。これにより、古い非アクティブなアドレスの履歴を簡単に保持できます。

これと同じ手法を電話番号にも使用しました。さまざまな番号の電話番号を保存する必要があります。

于 2009-07-27T02:10:43.017 に答える
1

David C. Hay の「Data Model Patterns - Conventions of Thought」を読むことを強くお勧めします。この問題は、著者によって詳細に議論されています。
デザインには、2 つの広範なエンティティがあります。

  1. 地理的な場所の住所
  2. 住所に存在する/所属する人/物

一般に、以下のように同じテーブルで住所と人物またはオブジェクトの詳細を組み合わせることはお勧めできません。

Person(personID, name, gender, addressline1, addressline2)

設計に次のエンティティを含めることができます

Address(number, street, countyID,stateID)
Party(PartyID, Type)
Person(PersonID, name, dob, gender,...,primaryPartyID)
Car(carID, make, model, ...,primaryPartyID)

パーティーは、人/車と住所との間のリンクです。person テーブルと Car テーブルの primaryPartyID は、party テーブルへの外部キーです。このようにして、車と人の間で共有してアドレス指定できます。人物ごとに複数のアドレスを保存したい場合は、人物とパーティの間に別の m:n テーブルを追加できます。Party の type 属性は、次の値を取ることができます: 'Person', 'Vehicle' など...

于 2009-07-29T08:43:28.393 に答える
0

ドロップダウン リストからのルックアップである AddressType フィールドがあると思います

于 2009-07-27T02:07:28.480 に答える