1. Dom
  2. Pytanie i odpowiedź
  3. Jak najlepiej reprezentują adresów w bazie danych

Jak najlepiej reprezentują adresów w bazie danych

2009-09-18 9 views
9

Możliwe duplikaty:
Is there common street addresses database design for all addresses of the world?
What is the “best” way to store international addresses in a database?
Best practices for consistent and comprehensive address storage in a databaseJak najlepiej reprezentują adresów w bazie danych

Obecnie mam cztery stoły, klientów, kontaktów, sprzęt i klientów.

Każda z poniższych tabel ma następujące pola: AddressLine1, AddressLine2, City, StateOrProvince, PostalCode.

Chciałbym przenieść adresy do oddzielnej tabeli i być w stanie również określić typ adresu (fakturowanie, dostawa, główna itd.).

Moje rozwiązanie jest następujące:

  1. Usuń AddressLine1, AddressLine2, miasto, StateOrProvince, postalCode od klientów, kontaktów, udogodnień i Klientów.
  2. Utwórz tabelę adresów z polami AddressID (PK), AddressLine1, AddressLine2, City, StateOrProvince, PostalCode, LastUpdateUser, LastUpdateTime.
  3. Tworzenie AddressTypes tabelę z polami AddressTypeID, AddressTypeName, AddressTypeDescription, AddressTypeActive, LastUpdateUser, LastUpdateTime
  4. Tworzenie CustomerAddresses tabelę z polami IDklienta, AddressID, AddressTypeID, CustomerAddressActive, LastUpdateUser, LastUpdateTime
  5. Tworzenie ClientAddresses tabelę z polami ClientID, AddressID, AddressTypeID, ClientAddressActive, LastUpdateUser, LastUpdateTime
  6. Tworzenie ContactAddresses tabelę z polami ContactID, AddressID, AddressTypeID, ContactAddressActive, LastUpdateUser, LastUpdateTime
  7. Tworzenie FacilityAddresses tabelę z pola s FacilityID, AddressID, AddressTypeID, FacilityAddressActive, LastUpdateUser, LastUpdateTime

szukam wskazówek, aby ustalić, czy istnieje lepsze rozwiązanie niż ta, którą wymyślił. Dlaczego wszyscy myślą?

EDYCJA: W tej chwili nie interesuje mnie nic poza Stanami Zjednoczonymi, a nie dotyczy to sposobu zapisywania adresu ulicy, tj. Numeru ulicy w stosunku do całego adresu ulicy. Obawiam się z punktu widzenia projektu bazy danych i struktury tabel.

Źródło

2009-09-18 Michael Wheeler

+1

Zobacz: http://stackoverflow.com/questions/24481/ http://stackoverflow.com/questions/126207/ http://stackoverflow.com/questions/929684/ http://stackoverflow.com/questions/310540/etc – Welbog

+0

Co jest nie tak z posiadaniem więcej niż jednej tabeli adresów? – NoChance

Odpowiedz

6

DBA gdzie użyłem do pracy powiedział mi ten klejnot, i to było wspaniałe dla nas (dwa pierwsze kroki są takie same jak w roztworze):

  1. Usuń AddressLine1, AddressLine2, miasto, StateOrProvince , Kod pocztowy od klientów, kontaktów, udogodnień i klientów.
  2. Tworzenie AddressTypes tabelę z polami AddressTypeID, AddressTypeName, AddressTypeDescription, AddressTypeActive, LastUpdateUser, LastUpdateTime
  3. tworzyć adresów tabelę z polami AddressID (PK), AddressTypeID (FK), AddressLine1, AddressLine2, miasto, StateOrProvince, postalCode, LastUpdateUser, LastUpdateTime , ID klienta (FK), identyfikator klienta (FK), identyfikator kontaktu (FK), identyfikator obiektu (FK) 4. W tabeli adresów ustaw ograniczenie tak, aby tylko jeden z identyfikatorów IDklienta, identyfikatora klienta, identyfikatora kontaktu lub identyfikatora klucza FacilityID mógł być nie-NULL na raz.

W ten sposób masz wszystkie swoje adresy w jednej tabeli, mogą one odnosić się do każdego rekordu, którego potrzebujesz, integralność referencyjna jest nienaruszona, a nie masz w tabeli pośredniej, którą musisz przemierzyć.

Wadą jest to, że jeśli chcesz dodać adresy do nowej klasy obiektu (np. Tabeli pracownika), musisz dodać kolumnę EmployeeID do tabeli adresów, ale to całkiem proste.

Źródło

2009-09-18 16:50:52

+0

Jaki jest sens dodawania tylu kluczy podstawowych, gdzie odwrotność może ułatwić życie i pozwolić na relacje, w których klienci (tylko próbka) mogą mieć więcej niż jeden adres. –

+2

Klient * może * mieć więcej niż jeden adres. Tabela adresów może zawierać wiele wierszy, które odwołują się do tego samego identyfikatora klienta. Po prostu nie można podać tego samego adresu zarówno dla klienta, jak i dla kontaktu. –

+0

co jeśli adres odnosi się do dwóch różnych klientów, ponieważ mieszkają w tym samym domu? – nonsensecreativity

0

Chcę również dodać jeszcze jedną rzecz, ze względu na prostotę, tworzyć widoki, które rozszerzają informacje adresowe do twoich tabel lub możesz nienawidzić się za projektowanie db w ten sposób.

Źródło

2009-09-18 16:10:48

0

Pomyślę pojedynczy AddressLink (nazwa?) Tablica z

LinkTypeID (Customer,Client,Contact,Facility) -- needs additional TypeID table 
ID (CustomerID,ClientID...) 
AddressID 
AddressTypeID 
AddressActive 
LastUpdateUser 
LastUpdateTime

Dodanie nowego typu łącza adres oznacza dodanie nowego LinkTypeID w/oa nowego [TypeID] Tablica adresów żadnych zapytań muszą być zmodyfikowane, a jeśli szukasz wszystkich zastosowań adresu (w przypadku usunięcia itp.), jest tylko jedno miejsce do wyszukania.

Jest to podobne do tego, jak to robimy.

Aha, i mamy adresLine3 w naszej tabeli adresów (odpowiednik) dla niektórych dziwnych sytuacji oddalonych.

Źródło

2009-09-18 16:23:19 DaveE

+1

W jaki sposób można wymusić ograniczenie klucza obcego na identyfikatorze z tą strukturą? Czy nie zawracasz sobie tym głowy? – APC

+0

Wstawianie/modyfikowanie wyzwalaczy pozwala sprawdzić, czy kolumna ID jest poprawna względem obiektu LinkTypeID. FKs w kolumnach LinkTypeID, AddressID i AddressTypeID oraz "delete restrict" w miejscu na tabelach nadrzędnych. Ja * myślę *, że jest to robione deklaratywnie, ale mogą być również wyzwalacze. (MS SQL Server 2005) – DaveE

1

Jedną dodatkową rzeczą, którą mamy w naszej bazie danych, którą moglibyśmy chcieć rozważyć, jest posiadanie flagi korespondencji na tablicy adresowej z wyzwalaczem, aby wymusić, że tylko jeden adres na osobę może postawić jako korespondencję. Wysyłamy wiele listów do osób znajdujących się w naszej bazie danych i wiemy, który z trzech adresów tej osoby jest tym, z którego musimy skorzystać, gdy wysyłanie poczty jest nieocenione. Ułatwia to również wysyłanie zapytań w celu pobrania tylko jednego adresu na osobę, aby uniknąć pobierania wielu rekordów na osobę w przypadku niektórych raportów.

Źródło

2009-09-18 17:06:01 HLGEM

Powiązane problemy

 Powiązane problemy