Welche Tabellen in Datenbank?

Sers,

programmiere grade eine Adressenverwaltung als Webanwendung und benutze eine MySQL Datenbank. Nun würde ich um Rat fragen wie die Tabellen etc. darin aussehen sollen.

Spalten: id lastname firstname location postalcode street street_altern1 street_altern2 location_altern1 location_altern2 phone1 phone2 fax1 fax2 mobilephone

Ich würde es dann so machen:

Tabelle: contact
Id lastname firstname locationid addressid communicationid

Tabelle: location
Id postalcode location

Tabelle: address
Id street street_altern1 street_altern2 location_altern1 location_altern2

Tabelle: communication
Id phone1 phone2 fax1 fax2 mobilephone

Jegliche Verbesserungen sind erwünscht, bin mir vorallem wegen den Alternativen nich so sicher... ggf. für Alternativen noch Tabelle/n?

Vielen Dank im voraus.

Lg

location_altern1 & location_altern2 würde ich hoch in die Tabelle "location" packen... Wieso sollten die alternativen denn nicht beim primären dabei sein ? :D
Bei dem Rest musst du auf antworten von anderen warten... Ich würd's so machen wie du ^.^

Quote:

Wieso sollten die alternativen denn nicht beim primären dabei sein ?

Wegen Redundanz dachte ich. Wenn paar Leute im selben Ort leben dann haste das durch die Alternativen zwangsweise mehrfach drin. Wenn man die Alternativen z.b. in eigene Tabelle packt hätte ich jeden Ort und jede Straße nur 1x in der db.... bin mir aber auch nich so sicher.

Sonst noch jemand ne idee?

Contact
ContactID
Lastname
Firstname
FKLocationID
FKCommunicationID

Location
LocationID
Postalcode
Location

Address
AddressID
FKContactID
Street
Location

Communication
CommunicationID
Phone1
Phone2
Fax1
Fax2
Mobilephone

Communication könnte man natürlich noch optimieren...

Tabellenname
Primary Key
FK = Fremdschlüssel

Quote:

Originally Posted by ElDiabolus Contact ContactID Lastname Firstname FKLocationID FKCommunicationID Location LocationID Postalcode Location Address AddressID FKContactID Street Location Communication CommunicationID Phone1 Phone2 Fax1 Fax2 Mobilephone Communication könnte man natürlich noch optimieren... Tabellenname Primary Key FK = Fremdschlüssel

Da hatte wohl jemand anständigen Datenbanken Unterricht!
Ich würde dir außerdem empfehelen InnoDB zu benutzen.
Ist irgendwie von der Perfomance besser.

Ich würde es noch etwas anders machen.

Die Adresse sollte nicht auf den Kontakt zeigen, sondern der Kontakt auf die Adresse. Es können schließlich mehrere Personen im selben Haus wohnen und haben damit die selbe Adresse. Oder wenn man einer Person auch mehrere Adressen geben will, dann eben mit einer zusätzlichen Tabelle.

Die Adresse sollte den Verweis auf die Stadt haben, dann kann man nur beim Betrachten der Adress-Tabelle erkennen welche Adressen mit dem gleichen Strassennamen in unterschiedlichen Städten sind. Außerdem wird eine Person, wenn sie mehrere Adressen hat, die nicht alle in der selben Stadt haben, oder?

Bei der Telefonnummer könnte man die Tabelle komplett umbauen. ID, Number, Typ (Fax, Phone, Mobil als Zahl) und ContactID. Dann kann eine Person beliebig viele Telefonnummern haben, braucht aber kein Fax.


Edit (11.10.2015 10:40): Ich habe die sinnvolle Korrektur/Ergänzung von Pand0r eingefügt, siehe nächster Beitrag. Warum ich die Tabelle nicht selbst erstellt habe ist mir ein kleines Rätsel.

Edit (12.10.2015 01:05): Ich habe ein paar Ergänzungen bei Mashkin geklaut, siehe Beitrag 9, und einige kleine Änderungen an Namen und Reihenfolge vorgenommen.

Quote:

Originally Posted by ComputerBaer  Spoiler Contact ContactID Lastname Firstname Location LocationID Postalcode Location Address AddressID Street ( Hausnummer? ) FKLocationID ContactAddress FKContactID FKAddressID Communication CommunicationID Number Typ (Fax, Phone, Mobil als Zahl) FKContactID Tabellenname Primary Key FK = Fremdschlüssel

Zusätzlich dazu
CommunicationType
TypeID
Name

TypeId in Communication Tabelle dann als Fremdschlüssel

Mein Ansatz wäre folgender:

Contact:
ContactID
Lastname
Firstname

Area: (vorher "Location")
AreaID
(Country)
(State)
Postalcode
Name (vorher "Location")

Address:
AddressID
FKContactID
Street (evtl. noch Number?)
(Optional) (Adresszusatz)
FKLocationID

Communication:
CommunicationID
FKContactID
Identifier
Type (Phone, Fax, Mobile, Pager, ...)

Zusammenhänge:

• Contact has many Addresses
• Contact has many Communications
• Address belongs to Contact
• Address has one Area
• Area has many Addresses
• Area has many Contacts through Address (Address als Pivot)
• Communication belongs to Contact

Quote:

Originally Posted by Mashkin Area: (vorher "Location")

"City" wäre vermutlich auch ein passender Name. Immerhin dienen alle Informationen in dieser Tabelle dazu, eine Stadt eindeutig zu identifizieren. Ich habe diese Namensänderung mal bei mir vorgenommen.

Quote:

Originally Posted by Mashkin Type (Phone, Fax, Mobile, Pager, ...)

Solltest du da immer "Phone" oder "Fax" reinschreiben wollen, dann verbraucht das unnötig viel Speicherplatz. Die Lösung mit einer eigenen Tabelle ist da besser. Auch wenn man gezielt alle Telefon- oder(!) Faxnummer haben will, geht das über die TypeID wahrscheinlich schneller.

Quote:

Originally Posted by Mashkin [*]Address belongs to Contact

Ich denke es gibt so viele Häuser, in denen mehr als eine Familie wohnt, dass du ruhig von "Address has many Contacts" ausgehen kannst. Oder?

Quote:

Originally Posted by Mashkin [*]Communication belongs to Contact

Nur als Anmerkung: Das hier macht hingegen Sinn, weil eine Telefon- oder Faxnummer für gewöhnlich nur zu einer Person/Familie gehört und nicht für alle Familien gilt, die im selben Haus wohnen.

Quote:

Originally Posted by ComputerBaer "City" wäre vermutlich auch ein passender Name. Immerhin dienen alle Informationen in dieser Tabelle dazu, eine Stadt eindeutig zu identifizieren. Ich habe diese Namensänderung mal bei mir vorgenommen.

Schon, allerdings habe ich mich gefragt warum nicht schon im Original von "City" die Rede war.

Quote:

Originally Posted by ComputerBaer Solltest du da immer "Phone" oder "Fax" reinschreiben wollen, dann verbraucht das unnötig viel Speicherplatz. Die Lösung mit einer eigenen Tabelle ist da besser. Auch wenn man gezielt alle Telefon- oder(!) Faxnummer haben will, geht das über die TypeID wahrscheinlich schneller.

Ich würde evtl. den ENUM-Typ in Betracht ziehen - die Beispielnamen wären dann bloß Aliase. Das kommt darauf an, wie viel Flexibilität für Kontaktoptionen nötig sind.

Quote:

Originally Posted by ComputerBaer Ich denke es gibt so viele Häuser, in denen mehr als eine Familie wohnt, dass du ruhig von "Address has many Contacts" ausgehen kannst. Oder?

Das Gegenstück zu "Address has many Contacts" ist aber "Contact belongs to Address" womit nur eine Address pro Contact möglich wäre. Korrekt ist also "Address has many Contacts through ContactAddresses" mit Pivot-Tabelle.

In Anbetracht eines möglichen Adresszusatzes (wie in vielen Kontaktformularen üblich; bspw. "Appartment 3" oder die PostNummer bei Packstationen) könnte man aber auch davon ausgehen, dass Addresses eher spezifisch für einzelne Contacts sind.
Wenn man eine Address für einen Contact löscht, müsste man so stets das Pivot-Element (ContactAddress) löschen und prüfen, ob das Address-Element evtl. noch von anderen Pivot-Elementen referenziert wird.
Eine Änderungsoperation der Address müsste ebenfalls die Mehrfachbenutzung des Elements in Betracht ziehen, das Element duplizieren und das relevante Pivot-Element ändern.

Es wäre je nach Anwendung (besonders bei Zustelladressen) sogar sinnvoll, auch den Empfängernamen in der Entität zu speichern, anstatt ihn aus dem Contact zu bilden (z.B. bei Verwendung eines Alias/Stichworts):

Address:
AddressID
FKContactID
Line1
Line2
Street (evtl. noch Number?)
FKCityID

Quote:

Originally Posted by Mashkin Das Gegenstück zu "Address has many Contacts" ist aber "Contact belongs to Address" womit nur eine Address pro Contact möglich wäre. Korrekt ist also "Address has many Contacts through ContactAddresses" mit Pivot-Tabelle.

Das liegt jetzt daran, dass wir es wohl auf etwas andere Art gelernt haben. Für mich wären es "Ein Kontakt hat mehrere Adressen" und "Eine Adresse kann zu mehreren Kontakten gehören". Aus dieser n:m-Beziehungen ergibt sich dann automatisch, dass eine weitere Tabelle gebraucht wird.

Quote:

Originally Posted by Mashkin In Anbetracht eines möglichen Adresszusatzes (wie in vielen Kontaktformularen üblich; bspw. "Appartment 3" oder die PostNummer bei Packstationen) könnte man aber auch davon ausgehen, dass Addresses eher spezifisch für einzelne Contacts sind.

Das könnte man auch relativ einfach lösen.

ContactAddress
FKContactID
FKAddressID
Additional // Adresszusatz

Quote:

Originally Posted by Mashkin Wenn man eine Address für einen Contact löscht, müsste man so stets das Pivot-Element (ContactAddress) löschen und prüfen, ob das Address-Element evtl. noch von anderen Pivot-Elementen referenziert wird. Eine Änderungsoperation der Address müsste ebenfalls die Mehrfachbenutzung des Elements in Betracht ziehen, das Element duplizieren und das relevante Pivot-Element ändern.

Da hast du Recht, bei Änderungen an der Adresse oder beim Löschen ist es aufwändiger. Man könnte einfach aus Prinzip keine Adressen Löschen, sondern nur die Beziehungen zu den Kontakten. Und bei Änderungen könnte man auch immer eine neue Adresse anlegen. Später könnte eine andere Aufgabe (1x pro Woche/Monat) nach Adressen ohne Kontakt suchen und diese löschen, falls man das möchte.

Quote:

Originally Posted by Mashkin Es wäre je nach Anwendung (besonders bei Zustelladressen) sogar sinnvoll, auch den Empfängernamen in der Entität zu speichern, anstatt ihn aus dem Contact zu bilden

Das hier wirkt eher wie eine Adressverwaltung für Privatpersonen, die Sache mit den Zustelladressen können wir denke ich außer Acht lassen. Inhaltlich hast du natürlich Recht, dass Rechnungs- und Lieferadressen auch einen anderen Namen beinhalten können, als den des Kontoinhabers.