[opengeodb] nur deutschland

[Martin Trautmann]

Robert Böck wrote:

>>> Die Vorteile speziell für die Opengeodb wären, dass die SQL-Statements,
>>> um Daten abzufragen, bei weitem nicht so komplex wären, wie sie jetzt
>>> sind (momentan muss man u. a. ganz exzessiv mit Selbstbezügen arbeiten,
>>> um der Datenbank bestimmte Datensätze zu entlocken).
>> fuer bestimmte ja - aber gerade normalisiert ergeben sich
>> moeglicherweise mehr Bezuege als wenn man alles in eine einzige Tabelle
>> reinpfropft.
>
> In der Praxis werden sich für Abfragen weniger Bezüge ergeben, eben weil
> nicht alles in eine Tabelle reingestopft ist und somit schon die Bezüge
> für die Datenart (text_type) wegfallen.

Nun, du polemisierst hier mit "reingestopft" und "Saustall" und 
ignorierst dabei, dass wir nicht nur eine Kiste "Obst" mit durcheinander 
Äpfeln und Birnen haben, sondern jedes einzelne Obststück fein sortiert 
seinen Platz hat.

Nach meiner unfachmännischen Meinung ist es einer guten Datenbank total 
egal, ob die Daten nun normalisiert vorliegen oder mit einem Type 
etikettiert sind. Bei einer schlechten Datenbank wage ich die 
Behauptung, dass manche mit dem einen Ansatz besser zurechtkommen, 
manche mit dem anderen.

> Wenn man das, was jetzt in geodb_textdata drinsteckt,
> auseinanderklamüsert, dann reduziert es einerseits die Datenmenge, weil
> text_type wegfallen kann, andererseits vereinfacht es die Abfragen, weil
> ich keinen text_type dafür herziehen muss, nur um festzulegen, welche
> Art von Daten (PLZ, Ort, etc.) ich haben will.

Statt dessen musst du sagen, in welcher Tabelle nachgesehen werden muss. 
Nehmen wir ein  einfaches Beispiel: Suche mir mal in deinem Ansatz die 
Daten zum Eintrag "Hampuri" heraus. Du wirst damit wohl in der Kiste 
"rote Äpfel aus Neuseeland" suchen müssen:

INSERT INTO geodb_textdata 
VALUES(17838,500100000,'Hampuri','fi',0,0,null,null,'3000-01-01',300500000);


Wenn ich dich richt verstehe, möchtest du Hampuri nun nicht einsortieren 
nach
   textdata:500100000:fi -> Hampuri
sondern nach
   500100000_fi

Das lässt sich absolut einfach normalisieren:
INSERT INTO geodb_textdata_500100000_fi 
VALUES(17838,'Hampuri',0,0,null,null,'3000-01-01',300500000);

Ich kann dir die SQL-Datei gerne in dieser Form konvertierten, dann 
kannst du deine Behauptung belegen. Zeige mir aber erst mal, wie du die 
Suche nach "Hampuri" gestalten würdest, wenn du nun atomarisiert suchen 
musst nach Äpfel (Name, Type 5001*), rot (Unterscheidung nach 
allgemeinem Name, Kurzform, Langform, Sortierform, ..., hier also 
500100000) aus Neuseeland (hier die Sprachversion "fi").

Deine atomarisierte Suchfunktion muss hier also nachsehen, ob Hampuri in 
rote Äpfel aus Neuseeland liegt - oder vielleicht in der Kiste rote 
Äpfel aus Papua-Neuguinea (500100000_yi) oder in der Kiste rote Äpfel 
aus Hawai (500100000_he).

Womöglich musst du sogar noch kleinere Kisten anlegen, wie z.B. "grüner, 
fauler Apfel aus Deutschland", um den Regierungsbezirk Magdeburg zu finden:

INSERT INTO geodb_textdata VALUES(190,500100099,'Regierungsbezirk 
Magdeburg','de',1,1,null,null,'2007-06-30',300500000);

->
INSERT INTO geodb_textdata_500100099_de_ehem 
VALUES(190,'Regierungsbezirk 
Magdeburg',1,1,null,null,'2007-06-30',300500000);

Das ist der ehemalige Regierungsbezirk Magdeburg, der zum 30. Juni 2007 
aufgelöst wurde und daher wohl in die Kiste der "faulen Äpfel" gehört.

Konsequent weiter gedacht gehört der aber in die Kiste der faulen, 
grünen Äpfel aus Deutschland, die in Deutschland abgepackt wurden, von 
deutschen Erntehelfern, usw., um irgendwann auf dem Atom
  INSERT INTO geodb_textdata_500100099_de_1_1_ehem_x_y_z 
VALUES(190,'Regierungsbezirk Magdeburg');
anzukommen.

(nochmal zur Erinnerung:
Äpfel = Name;
grün = Name in Langform;
aus Deutschland = Sprache de;
in Deutschland verpackt = is_native_lang;
von deutschen Erntehelfern = is_default_name;
faul = valid_until in der Vergangenheit;
...)


>>> Es geht schon mal damit los, dass die Tabelle keinen primary key hat.
>>> loc_id ist ein foreign key.
>> Wie kommst du darauf, die loc_id waere kein primary key? Sie wird also
>> solcher verwendet.
>
> Weil die loc_id in der Tabelle geodb_locations der Primärschlüssel ist.
> Wenn ich nun geodb_locations.loc_id mit geodb_textdata.loc_id verknüpfe,
> folgt daraus, dass geodb_textdata.loc_id ein Fremdschlüssel ist.

Ah, ok, in der textdata ist sie tatsaechlich Fremdschlüssel. Du brauchst 
also noch eine Hilfstabelle, um der
geodb_location.loc_id darüber mitzuteilen, dass plz_id zu dieser loc_id 
gehört - und irgendwie scheinst du zu glauben, dass du mit diesen 
Hilfstabellen Platz sparst?


>>> Dann ist da alles mögliche drin, was gar nicht zusammengehört (also
>>> Postleitzahlen, Ortsnamen in verschiedenen Schreibweisen, Bundesländer,
>>> Regiertungsbezirke, etc.)
>> Das gehoert nicht zusammen, glaubst du? Seltsam.
>
> Genauso wie Äpfel, Birnen und Tomaten nicht zusammengehören. Die gehören
> auch in getrennte Kisten.

Ja, du kannst natürlich bei Apfel-Anton einkaufen und in Bertas 
Birnenladen die Birnen holen - ich gehe gleich zu Obi.

>>> Die Tabelle enthält Daten (text_val) und
>>> Metadaten (text_type) gleichermaßen. Alles wild durcheinander wie Kraut
>>> und Rüben.
>> Das hat mit Normalisierung aber wohl nichts mehr zu tun?
>
> Meiner Meinung nach schon. Weil text_type redundant ist. Wenn man das
> alles sinnvoll zerlegt, wird text_type überflüssig.

Mir scheint eher, du hast eine Abneigung gegen den text_type, weil du 
die Problematik noch nicht verstanden hast. Zugegeben, das ist beliebig 
kompliziert. Mit wildcard-Operationen auf 50001* wird manches 
leichter... Ich befürchte, du würdest dich bald vor lauter Kisten nicht 
mehr umdrehen können.

Was machst du beispielsweise, falls ich bald mal das einbaue:

500600000 - amtlicher Gemeindeschlüssel
500600010 - amtlich ergäntzter Gemeindeschlüssel
500600020 - frei ergänzter Gemeindeschlüssel
500600100 - Landes/Gemeindeschlüssel

Nimm z.B. Hamburg mit dem Gemeindeschlüssel 02000000.
Der Stadtbezirk Hamburg-Mitte ist einer von sieben Stadtbezirken mit dem 
frei ergänzten Gemeindeschlüssel 020000001 und weiteren 15 Stadtteilen 
wie z.B. Hamm-Nord mit Gemeindeschlüssel 02000000104

In manchen Orten sind diese Unternummerierungen amtlich, könnte also als 
500600010 markiert werden. Andernfalls mache ich diese Ergänzung frei 
Schnauze und schaffe mir diesen frei ergänzten Gemeindeschlüssel als 
extrem leistungsfähigen Primärschlüssel, der in den ersten beiden 
Stellen das Bundesland, den nächsten drei den Landkreis, dann den 
Regierungsbezirk und die Gemeinde benennt.

Wer mehrere Länder in einer Datenbank zusammenpackt, der kann sich die 
gesamten Hierarchies ersparen, wenn er statt dessen in 500600100 den 
Wert DE02000000104 findet - das ist die einfache Kombination von 
Länderabkürzung und 5006000?0



Schönen Gruß
Martin