SQL Wie sinnvoll ist die Zerlegung der Entität "Adresse"?

[Tersus]

Hallo,

meine Frage mag etwas banal erscheinen, ist aber durchaus ernst gemeint.


Adresse(id, nummer, straße, plz, ort)

Nun hat die Mustermax Str. tatsächlich Nummern von 1 bis 300.

Sollte ich, um die redundante Datenhaltung des Strings "Mustermax Str." in der Tabelle "Adresse" zu vermeiden, tatsächlich die Entität "Straße" auslagern und die Adresse lediglich referenzieren?

Straße(name)

Selbiges ist ja der Fall mit der Straßennummer. Es gibt unzählige Straßen mit der Nummer 1. Für den Ort und die PLZ ist es auch genaue das gleiche.

Im Prinzip würde sich eine Adresse also nur aus Referenz-Entitäten zusammensetzen.

Die Frage ist natürlich: Referenz-Wirrwarr vs. Speicherschonung. Es wird für die Referenzierung ein Zeiger verwendet, der ja auch Speicher belegt.


Vielen Dank für einleuchtende Antworten.

 

[mambokurt]

Kommt drauf an würde ich sagen. Wenn du eine Datenbank mit allen Adressen einer Stadt aufbaust würde das Auslagern der Hausnummer vielleicht Sinn machen, wenn du aber nur eine Tabelle mit zB Kundendaten oder so etwas pflegst würde ich mir die Arbeit nicht machen, zumal sich die Speicherschonung dadurch schon in Grenzen halten dürfte.

Praktisch wäre das natürlich wenn sich mal ein Straßenname ändert - ein Update und fertig (auf der anderen Seite ist es der Datenbank eigentlich relativ Wumpe ob sie nun bei einem Eintrag den Straßennamen ändert oder bei 300).

 

[Sil3nTst0RM]

Meiner Meinung nach kommt es drauf an...

1. Hat man viele verschiedene, lohnt es eher nicht.

2. Hat man viele gleiche, lohnt es sich.


Bei kleineren Aufgaben würde ich es der Übersicht wegen nicht machen.

 

[ryan_blackdrago]

Warum die Adresse so aufdröseln?
Würde ganz simpel die Zuordnung über eine Tabelle Kunde, Mitglied, was_auch_immer realisieren:

Kunde

Kundennummer
Name
Vorname
Straße
PLZ
Ort
usw.
usw.

 

[KillerCow]

Letztlich musst du dir immer den genauen Anwendungsfall anschauen und beurteilen, welche Form der Zerlegung für die konkrete Anwendung am sinnvollsten ist. Eine pauschale Aussage kann man da nicht treffen.

Die Frage ist natürlich: Referenz-Wirrwarr vs. Speicherschonung. Es wird für die Referenzierung ein Zeiger verwendet, der ja auch Speicher belegt.

Es geht aber nicht nur um Speicherschonung, wie du es nennst. Was ist z.B., wenn sich in deinem Beispiel ein Straßenname ändert und du nicht mit einer Referenz arbeitest? Dann darfst du vielleicht ein paar hundert Änderungen vornehmen. Kommt das häufiger vor, macht sich die Refenzierung vielleicht bezahlt (alleine schon durch die Laufzeit).

 

[Cool Master]

Speicherschonung? Meiner Meinung nach brauch man das nicht mehr. Alleine schon wegen cachen. Aber es kommt natürlich darauf an was du vor hast. Wenn das Ding auf dem Raspberry Pi laufen soll muss man natürlich optimieren. Läuft das am ende auf einem halbwegs guten Server eher weniger.

 

[kling1]

Warum die Adresse so aufdröseln?
Würde ganz simpel die Zuordnung über eine Tabelle Kunde, Mitglied, was_auch_immer realisieren:

Kunde

Kundennummer
Name
Vorname
Straße
PLZ
Ort
usw.
usw.

adress historie.. rechnungs adresse und unterschiedliche lieferadresse..

kommt auf den anwendungsfall an.. aber wenn du nicht so ein stadtverzeichniss.. machen möchtest.. würde ich nicht eine extra strassen tabelle anlegen..

 

[ella_one]

Hallo Tersus,

Die Entität "Adresse" sollte wie folgt geändert bzw. in die 3te Normalform überführt werden:
adresse(id, strasse_id, nummer, plz)
strasse(strasse_id, strasse)
plz_ort(plz, ort)

In der Tabelle Adresse wird der Name der Straße in der Tabelle strasse nachgeschlagen. Dies spart, da strasse_id vom Datentyp Long Integer ist, u.U. sehr viel Speicherplatz. Abhängig von der Anzahl unterschiedlicher Straßennamen kann durchaus auch der Datentyp Integer für das Datenfeld strasse_id in Frage kommen.

Die Hausnummer (nummer) auszulagern macht wenig Sinn.

Hier das Microsoft Access Diagramm:

Anhang anzeigen 508038

Viel Spaß

 

[Sil3nTst0RM]

In der 3ten Normalform bekommt der Ort aber auch eine ID, auch wenn die PLZ scheinbar eindeutig ist.

oder liege ich da falsch? Spätestens bei Stadtteilen mit gleicher PLZ ist das sinnvoll.

 

[BeiNacht]

Ja
PLZ ist ein schlechter natuerlicher Schluessel fuer den "Ort"

 

[kling1]

plz muss halt ein string sein.. da ein platz auch mit einer 0 anfangen kann.. und mehrere orte können sich ein plz teilen oder ein ort hat mehrere plz.. deswegen auch nicht eindeutig

 

[rob-]

Du kannst auch ruhig redundant speichern, wird meist in der Praxis auch so gemacht.
Speicherplatz ist billiger als Rechenzeit, lohnt bei heavy load Servern nicht es in Normalformen zu bringen.

Bei Online Shops z.B. siehst du auch nie ein Straßen Drop-Down. Die nehmen einfach Strings der User entgegen und speichern es redundant. So brauchst dich nicht um Groß- Kleinschreibung, ss und ß kümmern etc.

Bei der Abfrage bist du mit redundanz um ein vielfaches schneller.

 

[Tersus]

Vielen Dank für eure zahlreichen Antworten.

Ich habe mich nun doch entschieden, Straße in eine extra Entität auszulagern. Es wird eine Stadtdatenbank, keine Datenbank für ein Bestell-System.
Zusätzlich wird das Ziel-Datenbanksystem nicht etwa MySQL werden, sondern SQLite für Android. Hier ist mir Speicherplatzschonung lieber, obwohl es an sich langsamer ist, als andere Datenbanken.

Jetzt noch mal nachgefragt. Wieso sollte ich den Namen der Straße nicht als natürlichen Schlüssel verwenden, sondern stattdessen eine ID? Weil zwei LONGS (Privatschlüssel von "Straße" und Referenzschlüssel von "Adresse") und ein VARCHAR weniger Platz einnehmen, als zwei VARCHAR (Privatschlüssel von "Straße" und Referenzschlüssel von "Adresse")?

Grüße

 

[thecain]

Der Strassenname ist doch nie im Leben Unique... Jedes Dorf hat doch irgendwo ne Dorfstrasse...

oder hab ich dich jetzt falsch verstanden?

 

[Tersus]

Der Strassenname ist doch nie im Leben Unique... Jedes Dorf hat doch irgendwo ne Dorfstrasse...

Der Straßenname ist innerhalb einer Gemeinde eindeutig ... . Heißt für mich, Kopf einschalten und ein vernünftiges konzeptionelles Schema entwerfen.

 

[crvn075]

Sprechende Schlüssel haben nahezu nur Nachteile und sollten maximal als Suchschlüssel verwendet werden, sonst für nix. Der zusätzliche Speicherplatz für einen künstlichen Schlüssel ist doch zu vernachlässigen, selbst auf Android.

 

[asdfman]

Warum die Adresse so aufdröseln?
Würde ganz simpel die Zuordnung über eine Tabelle Kunde, Mitglied, was_auch_immer realisieren:

Kunde

Kundennummer
Name
Vorname
Straße
PLZ
Ort
usw.
usw.

Nicht jeder Mensch hat vor- und Nachnamen. Adressen im Ausland können auch massiv abweichen. Zum Beispiel eine zusätzlich anzugebende Provinz. Das ganze Thema ist viel viel Komplexer, als man auf Anhieb glaubt und eine so übersimple Lösung bricht einem ganz schnell auseinander.

 

[Magellan]

Selbiges ist ja der Fall mit der Straßennummer. Es gibt unzählige Straßen mit der Nummer 1. Für den Ort und die PLZ ist es auch genaue das gleiche.

Also das finde ich zumindest komplett sinnlos.

Wo soll der Vorteil davon liegen statt der Hausnummer 16 die ID 16 einzutragen? du brauchst nur ständig nen Join mehr, hast ne Tabelle mehr aber reduzierst die Datenmenge in der Tabelle mit den Straßen nicht.

Außerdem ist Hausnummer 1 ja nicht gleich Hausnummer 1 wenn sich da jetzt eine ändert änderst du so oder so nicht den Hausnummer Datensatz sondern nur die ID in betreffenden Adressdaten.

Der Straßenname ist innerhalb einer Gemeinde eindeutig ... . Heißt für mich, Kopf einschalten und ein vernünftiges konzeptionelles Schema entwerfen.

Naja aber du hast ja wohl Straßen mehrerer Gemeinden in einer Tabelle, dann brauchst du also entweder einen kombinierten PK oder es wird hässlich wenn sich ein Straßenname ändert und du dann statt wirklich den Namen zu ändern alle betreffenden FK austauschen musst.

Ich persönlich würde in den aller meisten Anwendungsfällen ein flaches Schema für Adressen bevorzugen, zumal das auch für die Suche bei den meisten Datenbanken nützlicher ist.