Fragen zu opengeodb (PLZ-Koordinaten, Performance, andere RDBMS)

[Robert Böck]

Stephan S wrote:

>> > Du hast hier schon mehrfach behauptet, bei der gegenwärtigen Datenbank-Struktur
>> > wäre von Normalisierung keine Spur, mich würde dazu mal interessieren, gegen
>> > welche Normalform Deiner Meinung nach verstoßen wird?
>>
>> geodb_textdata ist nicht atomar. Andere Tabellen auch nicht.
>
> Das ist eine Behauptung. Wo ist ein Beleg oder ein Beispiel? Welches
> Attribut enthält Deiner Meinung nach einen nichtatomaren Wertebereich?

Der Knackpunkt ist für mich geodb_textdata.text_type. Dieses Attribut
wäre überflüssig, würde man nicht verschiedene Datenarten in eine
Tabelle reinstopfen.

> [...]
>> > Die Behauptung, die Datenbankstruktur wäre ein "Saustall"
>> > ohne Belege dafür oder eine Alternative zu präsentieren, finde ich
>> > ehrlich gesagt etwas unverfroren,
>>
>> Du willst allen Ernstes behaupten, Kritik wäre nur zulässig, wenn man
>> gleichzeitig eine Alternative für das kritisierte Objekt anbietet?
>
> Nein, wenn Du nochmal genau liest, steht da, dass ich bei der Äußerung
> von Kritik in einer derart harschen Form, Belege für die aufgestellten
> Behauptungen oder zumindest einen Alternativ-Entwurf erwarte, denn das
> würde zeigen, dass du dich mit dem Gegenstand deiner Kritik auseinander
> gesetzt hast. Fundierte Kritik ist sehr willkommen, unreflektierte
> Schmähungen und Worthülsen nicht.

Ok, dann nochmal bildlich.

Wenn ich Äpfel, Birnen, Bananen, Tomaten, etc. zusammen in eine Kiste
reinwerfe, ist das für mich ein "Saustall". Wenn aber jede Gattung in
einer eigenen Kiste liegt, dann ist es sauber, aufgeräumt und klar
strukturiert.

>> Ich habe jedoch den Eindruck, dass derjenige, der die Datenbankstruktur
>> entworfen hat, noch nicht mal wusste, dass so etwas wie Normalisierung
>> überhaupt existiert.
>
> Zum einen habe ich den Eindruck, du hast dir nicht die Mühe gemacht das
> Mailinglisten-Archiv zu bemühen und die diesbezüglichen Mails zu lesen.
> OK, wäre auch etwas Arbeit.

Wo sollte ich deiner Meinung nach anfangen? Bei Adam und Eva? Das wäre
nicht nur etwas Arbeit, das wäre verdammt viel Arbeit.

> Weiterhin erwecken deine Äußerungen den Eindruck, dass du dich mal
> -ähnlich oberflächlich wie mit der opengeodb- mit Datenbank-Normalisierung
> beschäftigt hast und bei jeder Gelegenheit damit um dich wirfst.
> Normalisierung ist ein Konzept zur Vermeidung von Redundanzen und
> Inkonsistenzen, keine Religion.

Und was ist geodb_textdata.text_type? Ein Konzept zur Erzeugung von
Redundanzen?

> Zum dritten habe ich den Eindruck, dass Du dir noch immer nicht die Mühe
> gemacht hast, zu ergründen warum die Struktur so ist wie sie ist.

Glaube mir, ich hatte schon genug Mühe damit, zu ergründen, wie man der
Struktur die Daten entlocken kann, die man gerne haben möchte.

> Beim Entwickeln einer alternativen Struktur, die Art und Umfang der
> Information aufnehmen kann, die die opengeodb bietet hättest Du schnell
> gemerkt, dass eine "vereinfachte" Form wie sie dir vorschwebt dies nicht
> leisten kann.

Ich kann mir einfach nicht vorstellen, dass es nicht möglich sein soll,
die Opengeodb so zu strukturieren, dass die Struktur verständlicher wird.

> Versuche einfach mal in deiner vereinfachten Form die
> verschiedenen Hierarchie-Ebenen in unterschiedlichen Staaten oder
> Bundesländern abzubilden.

Das kann ich nicht, weil ich die Verwaltungsgliederung in anderen
Staaten nicht kenne.

>> > Die jetzige Struktur bietet die maximale
>> > Flexibilität aus der sich jeder die Daten, die er benötigt extrahieren
>> > kann, und das sollte meiner Meinung nach auch so bleiben!
>>
>> Flexibility through obscurity?
>
> Du verwechselst hier Ursache und Auswirkung, die Flexibilität wird nicht
> durch Unverständlichkeit erreicht.

Stimmt, ich habs falsch formuliert, aber es bot sich grad an. ;-)

Ich hätte wohl besser schreiben sollen:
Flexibility by accepting obscurity.

Oder anders gesagt: Was nutzt die ganze Flexibilität, wenn kaum einer
durchblickt?

> Dir erscheint es unverständlich, weil
> die Flexibilität einen höheren Abstraktionsgrad erzwingt. Wenn du aber
> glaubst, es gibt ein leichter verständliches Modell, das die gleiche
> Flexibilität bietet, dann ist hier jeder froh darüber. Immer her damit.

Ich habe keines parat und mir ist auch klar, dass man so ein Datenmodell
nicht einfach aus dem Ärmel schüttelt.

>> Trotzdem nehme ich mir das Recht heraus, Kritik zu üben.
>
> Das sei dir unbenommen, aber wenn Deine Kritik gehört und beachtet
> werden soll, sollte sie auch mit irgendetwas untermauert sein.

Schau dir doch die Postings hier der vergangenen Monate an. Immer wieder
wird deutlich, dass die Leute bei der Datenstruktur einfach nicht
durchblicken.

> Du mißverstehst die Motivation hinter opengeodb, hier werden Geodaten
> gesammelt, bearbeitet und zur Verfügung gestellt. Und dafür ist die
> bestehende Datenbank-Struktur entwickelt worden. Du willst die Struktur
> auf Deinen eingeschränkten Bedarf (Webanwendung o.ä.) hin optimieren,
> das kannst Du gerne für dich tun.

Nein, das siehst du falsch. Ich bin der Meinung, die Datenstruktur
sollte durchaus felexibel, aber trotzdem verständlich sein. Klar sollte
jeder die Daten, die er benötigt, in eine dafür passende Struktur
überführen. Und eine etwas verständlichere Struktur der Rohdaten wäre
dafür sicher nicht von Nachteil.

> Für eine Umkreissuche ist das
> bestehende Datenbankmodell sicherlich absolut ungeeignet und
> unperformant, da hast Du recht. Und deshalb ist jedem angeraten (wie
> hier schon hundertmal erwähnt wurde) sich die benötigten Informationen
> zu extrahieren und in eine für seinen Zweck passende Struktur zu
> überführen. Das kann und will die opengeodb nicht leisten.
>
> Du scheinst das ja -wie etliche vor dir- bereits erfolgreich
> durchgeführt zu haben, also wo liegt dein Problem?

Mein Problem liegt darin, dass es viele Leute gibt, die einfach nicht
durchblicken. Das kann man leicht erkennen, wenn man die Postings hier
ein wenig mitverfolgt.

Und mein Problem liegt darin, dass ich meine eigenen SQL-Statements, die
ich mir mal vor anderthalb Jahren zusammengeschustert habe, um die Daten
zu extrahieren, jetzt selbst auf Anhieb nicht mehr verstehe.

> Niemand hier glaubt, dass die Opengeodb in der jetzigen Form perfekt ist
> und jeder der helfen will sie zu verbessern ist hier gern gesehen. Dazu
> gehört aber die Bereitschaft etwas mehr einzubringen, als ein paar
> abwertende Statements.

Da kann ich leider nur sehr begrenzt beitragen, weil mir die
Voraussetzungen, insbesondre was Verwaltungsgliederungen anderer Staaten
anbelangt, nicht bekannt sind.

cu, Robo :)

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[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
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[admin-231]

> 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.
>

Natürlich hat jedes seinen Platz in der Kiste aber von fein sortiert kann ja
wohl keine Rede sein. Wenn Du nun alle Äpfel haben willst, musst Du hier
nämlich ganze Kiste auskippen und alles sortieren.

> 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.
>

Absolut falsch. Eine nicht normalisierte Datenbank ist niemals eine Gute.

> > 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;
> ...)
>

Also was Du hier schreibst ist genauso kompliziert gedacht, wie die Daten nun
vorliegen. Ich habe keine Ahnung was Du mit Hapuri da sagen willst. Ich wüsste
nicht mal ob das ein Ort ist, wenn ich nicht zufällig hier dieses Beispiel
schon gesehen hätte. Die finnische Übersetzung von Hamburg hat meines
Erachtens überhaupt nichts in geodb_textdata zu suchen. Das gehört halt in
eine andere Tabelle mit Übersetzungen wenn das wirklich geführt werden soll.
Habt Ihr von allen Orten die finnische Übersetzung? Wenn nein ist eine
Übersetzung absolut überflüssig ja sogar dazu geeignet die Daten inkonsistent
zu machen.

> >>> 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?
>

Und was macht ihr jetzt? Ihr benutzt ein ganzen Hilfsschlüsselkonstrukt der
mit reinem SQL nicht zu lösen ist. In einer guten Datenbank sind das auch
keine Hilfstabellen sondern eine perfekt verknüpfte Datensammlung die keine
redundanten Daten enthält.

> >>> 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

Hier genau ist das Problem. Diese Frage kann Dir keiner beantworten, da es
absolut nicht ersichtlich ist, wozu Du diese Gemeindeschlüssel brauchst und
inwiefern diese für die Gesamtheit der Daten relevant sind.
Hier kam auf, das kein Vorschlag gemacht wird, wie man es verbessern kann. Das
 ist einfach so unmöglich. Kaum einer weiß, was genau nun alles aufgenommen
werden soll. Es gibt hierzu keine Info. Wenn ich weiß welche Daten nun
wirklich in der Datenbank stehen, schreibe ich ein Datenbank Model dafür das
erheblich kleiner ist als das was jetzt da ist. Ich habe versucht 3 Tage lang
durch die Text Daten und die Datenstruktur zu blicken aber immer fand ich
Einträge mit denen ich einfach nichts anfangen kann. Dann habe ich einfach die
 locations in meine PLZ Datenbank eingespeist und alles Gehabt was ich brauchte.

Falls mir einer die relevanten Daten aufzeigen kann veröffentliche ich hier
ein Datenmodel das alle Gegebenheiten berücksichtigt.

Gruß

Andrew


> --
> Mailingliste OpenGeoDB
> Listenadresse: opengeodb@...
> Informationen: http://opengeodb.de
> Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)
------- End of Original Message -------

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

admin@... wrote:

> Also was Du hier schreibst ist genauso kompliziert gedacht, wie die Daten nun
> vorliegen.

Für jemanden, der einfach nur eine Umkreissuche auf eine PLZ machen
will, ist das sicher zu kompliziert - das war übrigens eine der
Erweiterungen, für die opengeodb eigentlich nicht gedacht war, die aber
gerne und häufig gewollst ist und die mit hineinwachsen konnte.
Für eine wachsende Sammlung an mehr oder weniger interessanten
Informationen ist für solche Komplikationen Platz.

> Ich habe keine Ahnung was Du mit Hapuri da sagen willst. Ich wüsste
> nicht mal ob das ein Ort ist, wenn ich nicht zufällig hier dieses Beispiel
> schon gesehen hätte. Die finnische Übersetzung von Hamburg hat meines
> Erachtens überhaupt nichts in geodb_textdata zu suchen. Das gehört halt in
> eine andere Tabelle mit Übersetzungen wenn das wirklich geführt werden soll.

Es war ein willkürliches Beispiel - und es zeigt die Frage, ob es in die
gleiche Tabelle gehört (vergleiche mehrsprachige Länder wie die
Schweiz), ob es in eine Tabelle mit Übersetzungen gehört oder ob es gar
in eine Tabelle mit finnischen Übersetzungen gehört.

> Habt Ihr von allen Orten die finnische Übersetzung?

Nein, weil es ohnehin nicht für alle Städte eine solche Übersetzung
gibt. Das Beispiel passte gerade recht gut. Eine Suche nach "Genfer See"
wird aber wohl jeder zurecht erwarten, auch wenn der eigentlich primär
als "Lac Léman" zu führen ist.

> Wenn nein ist eine
> Übersetzung absolut überflüssig ja sogar dazu geeignet die Daten inkonsistent
> zu machen.

Du meinst also, wir müssen alle Einträge rauswerfen, für die wir keine
PLZ kennen? Woher kommt dieser Anspruch, alles müsse von Anfang an
vollständig sein?

> Und was macht ihr jetzt? Ihr benutzt ein ganzen Hilfsschlüsselkonstrukt der
> mit reinem SQL nicht zu lösen ist. In einer guten Datenbank sind das auch
> keine Hilfstabellen sondern eine perfekt verknüpfte Datensammlung die keine
> redundanten Daten enthält.

Man möge eine solche Datenbank zeigen und deren Vorteil belegen. Ob ich
es in das eine Exportformat konvertiere oder in das andere, ist mir
sowas von egal. Dafür sollte aber nachweisbar sein, dass das Resultat
besser wird.

Schon die derzeit fehlenden Hierarchies wurden massiv beklagt - und das
sind eindeutig redundante Daten.


> Hier genau ist das Problem. Diese Frage kann Dir keiner beantworten, da es
> absolut nicht ersichtlich ist, wozu Du diese Gemeindeschlüssel brauchst und
> inwiefern diese für die Gesamtheit der Daten relevant sind.

Diese Schlüssel sind für mich relevant, daher nutze ich sie - und ich
weiss aus Gesprächen, dass dies für andere interessant sein kann, die
genau sowas brauchen. Ob es für jedermann interessant ist, das kann ich
eindeutig verneinen - nur wenige kennen derzeit überhaupt den amtlichen
Gemeindeschlüssel.

> Hier kam auf, das kein Vorschlag gemacht wird, wie man es verbessern kann. Das
>   ist einfach so unmöglich. Kaum einer weiß, was genau nun alles aufgenommen
> werden soll. Es gibt hierzu keine Info. Wenn ich weiß welche Daten nun
> wirklich in der Datenbank stehen, schreibe ich ein Datenbank Model dafür das
> erheblich kleiner ist als das was jetzt da ist. Ich habe versucht 3 Tage lang
> durch die Text Daten und die Datenstruktur zu blicken aber immer fand ich
> Einträge mit denen ich einfach nichts anfangen kann. Dann habe ich einfach die
>   locations in meine PLZ Datenbank eingespeist und alles Gehabt was ich brauchte.

Sprich, du bist wohl einer, denen PLZ.tab voll und ganz ausreicht? qed
Andere wollen aber mehr haben. Manche interessieren sich für
Einwohnerzahlen, manche für Einwohnerentwicklungen, manche für
Telefonvorwahlen. Würde man nur jene Einträge drinlassen, die mindestens
das vollständig enthalten, so wäre die opengeodb recht klein - und
ohnehin permanent veraltet. Im Moment hat man aber die Möglichkeit, sich
das herauszunehmen, was man braucht.

> Falls mir einer die relevanten Daten aufzeigen kann veröffentliche ich hier
> ein Datenmodel das alle Gegebenheiten berücksichtigt.

Ein guter Anfang ist schon mal
http://fa-technik.adfc.de/code/opengeodb/opengeodb-end.sql (Auszug s.u.)
und je nach Bedarf zum Nachschlagen
http://fa-technik.adfc.de/code/opengeodb/opengeodb-begin.sql

Nicht alles davon wird derzeit überhaupt genutzt - die Anzahl der
Einträge lässt sich durch SQL-Abfragen sicher leicht feststellen.

type     Typ
100100000 'Erdteil'
100200000 'Staat/Land'
100400000 'Regierungsbezirk'
100500000 'Landkreis'
100600000 'Politische Gliederung'
100700000 'Ortschaft'
100800000 'Postleitzahlgebiet'
100900000 'Ortsteil'
200100000 'WGS84 Koordinaten'
200200000 'lat'
200300000 'lon'
300100000 'Auf einen Tag genaues Datum'
300200000 'Auf ein Monat genaues Datum'
300300000 'Auf ein Jahr genaues Datum'
300400000 'Auf 10 Jahre genaues Datum'
300500000 'Unbekanntes Datum in der Zukunft'
400100000 'Teil von'
400200000 'Ebene'
400300000 'Typ'
500100000 'Name'
500100001 'ISO 3166 Alpha-2'
500100002 'Sortiername'
500100003 'ISO_3166_2'
500100004 'Region eines Postleitzahlgebietes'
500300000 'Postleitzahl'
500400000 'Telefonvorwahl'
500500000 'KFZ-Kennzeichen'
500600000 'Amtlicher Gemeindeschlüssel'
500700000 'Verwaltungszusammenschluss'
500700001 'Sortiername eines Verwaltungszusammenschlusses'
500800000 'Quelle'
500900000 'Kommentar'
600700000 'Einwohnerzahl'
600800000 'Höhenangabe in Metern'
610000000 'Fläche'
650700001 'Ungefähre Einwohnerzahl'
650700002 'Genaue Einwohnerzahl'
650800001 'Maximale Höhe'
650800002 'Minimale Höhe'
650800003 'Durchschnittliche Höhe'
650800004 'Höhe am Referenzpunkt mit der angegebenen loc_id'
650800005 'Höhe an der angegebenen Koordinate'
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Lucas Mengel]

So sehe ich das auch!
Ich habe auch nie verstanden, warum es diese text_type
überhaupt gibt. Man könnte geenauso gut tabellen machen,
dann würde man das wenigstens noch verstehen! und pflegen
kann man das genauso gut!
Ich würde auch schon damit anfangen und das Ergebnis hier
publizieren, wenn ich denn das aktuelle Modell verstehen
würde!!!

admin@... schrieb:

>> 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.
>>
>
> Natürlich hat jedes seinen Platz in der Kiste aber von fein sortiert kann ja
> wohl keine Rede sein. Wenn Du nun alle Äpfel haben willst, musst Du hier
> nämlich ganze Kiste auskippen und alles sortieren.
>
>> 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.
>>
>
> Absolut falsch. Eine nicht normalisierte Datenbank ist niemals eine Gute.
>
>>> 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;
>> ...)
>>
>
> Also was Du hier schreibst ist genauso kompliziert gedacht, wie die Daten nun
> vorliegen. Ich habe keine Ahnung was Du mit Hapuri da sagen willst. Ich wüsste
> nicht mal ob das ein Ort ist, wenn ich nicht zufällig hier dieses Beispiel
> schon gesehen hätte. Die finnische Übersetzung von Hamburg hat meines
> Erachtens überhaupt nichts in geodb_textdata zu suchen. Das gehört halt in
> eine andere Tabelle mit Übersetzungen wenn das wirklich geführt werden soll.
> Habt Ihr von allen Orten die finnische Übersetzung? Wenn nein ist eine
> Übersetzung absolut überflüssig ja sogar dazu geeignet die Daten inkonsistent
> zu machen.
>
>>>>> 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?
>>
>
> Und was macht ihr jetzt? Ihr benutzt ein ganzen Hilfsschlüsselkonstrukt der
> mit reinem SQL nicht zu lösen ist. In einer guten Datenbank sind das auch
> keine Hilfstabellen sondern eine perfekt verknüpfte Datensammlung die keine
> redundanten Daten enthält.
>
>
>>>>> 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
>
> Hier genau ist das Problem. Diese Frage kann Dir keiner beantworten, da es
> absolut nicht ersichtlich ist, wozu Du diese Gemeindeschlüssel brauchst und
> inwiefern diese für die Gesamtheit der Daten relevant sind.
> Hier kam auf, das kein Vorschlag gemacht wird, wie man es verbessern kann. Das
>  ist einfach so unmöglich. Kaum einer weiß, was genau nun alles aufgenommen
> werden soll. Es gibt hierzu keine Info. Wenn ich weiß welche Daten nun
> wirklich in der Datenbank stehen, schreibe ich ein Datenbank Model dafür das
> erheblich kleiner ist als das was jetzt da ist. Ich habe versucht 3 Tage lang
> durch die Text Daten und die Datenstruktur zu blicken aber immer fand ich
> Einträge mit denen ich einfach nichts anfangen kann. Dann habe ich einfach die
>  locations in meine PLZ Datenbank eingespeist und alles Gehabt was ich brauchte.
>
> Falls mir einer die relevanten Daten aufzeigen kann veröffentliche ich hier
> ein Datenmodel das alle Gegebenheiten berücksichtigt.
>
> Gruß
>
> Andrew
>
>
>> --
>> Mailingliste OpenGeoDB
>> Listenadresse: opengeodb@...
>> Informationen: http://opengeodb.de
>> Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)
> ------- End of Original Message -------
>

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Thomas Wicht]

Den text_type gibt es um den Wert text_val eine Bedeutung zu geben,
wenn ich Postleitzahlen abfragen möchte gebe ich den text_type dazu an.

Das einzig nervige an der opengeodb ist, das Ihr die Tabelle hierachies leer
mitliefert
den diese ist der Schlüssel zu allen. Ohne diese kann man einfach die Daten
nicht mehr
einfach mit JOINS auf die Tabellen abfragen.

Wenn Ihr für alles eine extra Tabelle machen wollt, so müsst Ihr wieder x
Tabellen
erstellen die plz mit Stadtteilen verbinden, Stadtteile mit Orten , Orte mit
Bundesländern , Bundesländer mit Ländern

Und genau dies hatte eigentlich mal die hierachies Tabelle übernommen.

Ich sehe das Problem eher in der mangelten Dokumentation und fehlenden
Beispielen. Jeder der
das erste Mal mit der geodb arbeitet bekommt einen Anfall, aber nach und
nach ergibt das schon einen Sinn.

Aber man muss sich einfach zu viel zusammenreimen und probieren, bis zb im
alten modell id_lvl3
einen Sinn ergibt.

Und jeder kann sich die Daten aus der DB ziehen die er für sein Projekt
benötigt,
das einzig problematische dabei ist, wenn immer wieder was an der DB
Struktur geändert wird
so wird jedes update zu einer nervigen Sache. So musste ich nachdem die
Hierarchies wegfallen sind
stundenlang im Netz suchen und lesen was Ihr Euch wieder als nächstes
ausgedacht habt und
wie ich jetzt mit den Daten die hierarchies wieder füllen kann.

----- Original Message -----
From: "Lucas Mengel" <froschpopo@...>
To: <admin@...>; "Mailingliste OpenGeoDB" <opengeodb@...>
Sent: Tuesday, March 18, 2008 10:08 AM
Subject: Re: [opengeodb] nur deutschland


So sehe ich das auch!
Ich habe auch nie verstanden, warum es diese text_type
überhaupt gibt. Man könnte geenauso gut tabellen machen,
dann würde man das wenigstens noch verstehen! und pflegen
kann man das genauso gut!
Ich würde auch schon damit anfangen und das Ergebnis hier
publizieren, wenn ich denn das aktuelle Modell verstehen
würde!!!

admin@... schrieb:

>> 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.
>>
>
> Natürlich hat jedes seinen Platz in der Kiste aber von fein sortiert kann
> ja
> wohl keine Rede sein. Wenn Du nun alle Äpfel haben willst, musst Du hier
> nämlich ganze Kiste auskippen und alles sortieren.
>
>> 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.
>>
>
> Absolut falsch. Eine nicht normalisierte Datenbank ist niemals eine Gute.
>
>>> 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;
>> ...)
>>
>
> Also was Du hier schreibst ist genauso kompliziert gedacht, wie die Daten
> nun
> vorliegen. Ich habe keine Ahnung was Du mit Hapuri da sagen willst. Ich
> wüsste
> nicht mal ob das ein Ort ist, wenn ich nicht zufällig hier dieses Beispiel
> schon gesehen hätte. Die finnische Übersetzung von Hamburg hat meines
> Erachtens überhaupt nichts in geodb_textdata zu suchen. Das gehört halt in
> eine andere Tabelle mit Übersetzungen wenn das wirklich geführt werden
> soll.
> Habt Ihr von allen Orten die finnische Übersetzung? Wenn nein ist eine
> Übersetzung absolut überflüssig ja sogar dazu geeignet die Daten
> inkonsistent
> zu machen.
>
>>>>> 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?
>>
>
> Und was macht ihr jetzt? Ihr benutzt ein ganzen Hilfsschlüsselkonstrukt
> der
> mit reinem SQL nicht zu lösen ist. In einer guten Datenbank sind das auch
> keine Hilfstabellen sondern eine perfekt verknüpfte Datensammlung die
> keine
> redundanten Daten enthält.
>
>
>>>>> 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
>
> Hier genau ist das Problem. Diese Frage kann Dir keiner beantworten, da es
> absolut nicht ersichtlich ist, wozu Du diese Gemeindeschlüssel brauchst
> und
> inwiefern diese für die Gesamtheit der Daten relevant sind.
> Hier kam auf, das kein Vorschlag gemacht wird, wie man es verbessern kann.
> Das
>  ist einfach so unmöglich. Kaum einer weiß, was genau nun alles
> aufgenommen
> werden soll. Es gibt hierzu keine Info. Wenn ich weiß welche Daten nun
> wirklich in der Datenbank stehen, schreibe ich ein Datenbank Model dafür
> das
> erheblich kleiner ist als das was jetzt da ist. Ich habe versucht 3 Tage
> lang
> durch die Text Daten und die Datenstruktur zu blicken aber immer fand ich
> Einträge mit denen ich einfach nichts anfangen kann. Dann habe ich einfach
> die
>  locations in meine PLZ Datenbank eingespeist und alles Gehabt was ich
> brauchte.
>
> Falls mir einer die relevanten Daten aufzeigen kann veröffentliche ich
> hier
> ein Datenmodel das alle Gegebenheiten berücksichtigt.
>
> Gruß
>
> Andrew
>
>
>> --
>> Mailingliste OpenGeoDB
>> Listenadresse: opengeodb@...
>> Informationen: http://opengeodb.de
>> Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)
> ------- End of Original Message -------
>

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[uwe-4]

Wer hätte nicht gerne alles fertig und perfekt auf seine Bedürfnisse,
sein Projekt zugeschnitten!?
Der Martin versucht doch nun schon zum hundertsten mal, für mich
ziemlich einleuchtend zu erklären, warum welche Daten wie abgelegt sind.
Man muss auch gar nicht seine Ansichten zum Aufbau "ordentlicher"
Datenbanken und SWL teilen, tue ich im Übrigen auch nicht, aber was zum
Henker ist denn so schwer daran, sich aus den verdammt umfangreichen
Daten, seine bevorzugte DB-Struktur aufzubauen und zu füllen.

Dank der Typen ist doch sehr gut ersichtlich um was für eine Art Datum
es sich handelt.
Brauch ich also nur PLZ, ne Art Hierarchie
Kontinent->Land->Bundesland->Stadt->Stadtteil und vielleicht noch die
Übersetzung und die Einwohnerzahl, dann nehme ich nur die Daten und lege
mir diese so ab, wie ich das gern hätte.
Dem einen ist es für seine Mini-Homepage egal, ob die Daten dann in der
4. Normalform da liegen, der schmiert halt alles in eine Tabelle. Ein
anderer braucht größtmögliche Flexibilität, Ordnung, referenzielle
Integrität und ein wunderbar sauberes DB-Schema, der schreibt die Daten
halt in seine sauber angelegten Detailtabellen und führt eine schmale
saubere Stammtabelle.

Sollte es bei der Umsetzung an 1,2 Verständnisfragen zu den Typen oder
ähnlichen scheitern ist Martin sicher der allerletzte, der dazu keine
Auskunft erteilen wird.

Was aber dieses ständige in Frage gestelle von bestimmten Daten soll
erschließt sich mir absolut nicht. Wer keinen Gemeindeschlüssel braucht
lässt ihn halt weg.
Mal ganz nebenbei wird der zum Beispiel auch bei Wiki für viele Städte
und Gemeinden mitgeführt, weil er halt für viele interessant sein kann.
Ist halt ein "Ding" zur Identifizierung und Abgrenzung von Gebieten,
hier politische selbständigen Gebieten. Nicht viel anders als ne
Postleitzahl. Manche können es gebrauchen, manche nicht und manche
wissen halt nicht was das ist.

Ich hätte auch nicht zwingend die finnische Übersetzung von Hamburg
gekannt, aber wer ein internationales Web-Angebot erstellen will, wird
sicher dankbar sein auch finnischen Nutzern z.B. in einer Suche helfen
zu können.
Und nur weil nicht für jede Stadt eine Übersetzung da ist, diese nicht
mitzuführen ist ja wohl etwas engstirnig. So nach dem Motto, weil noch
nicht jeder Nutzer im Shop etwas bestellt hat brauch ich auch keine
Tabelle / Spalte Order. oder wie?
Mal ganz davon ab, dass es halt nun mal ein Fakt ist, dass es für
diverse Städte landes- bzw. sprachentypische Übersetzungen gibt, für
andere nun mal nicht.

Wenns hilft könnte man ja ein Tool bereitstellen, welches die Struktur
der OpenGeoDB kennt und darstellt und jeder sich spalten und Typen
zusammenklickern die er gerne hätte und in was für Tabellen und das Tool
generiert das dann und stellt die Daten zum Download bereit. Wird zwar
nciht ganz in Echtzeit gehen, aber mit nem Versatz von 1,2 Stunden
mittels eines Cronjobs sehe ich da kein Problem.

Gruß Uwe


Lucas Mengel wrote:

> So sehe ich das auch!
> Ich habe auch nie verstanden, warum es diese text_type
> überhaupt gibt. Man könnte geenauso gut tabellen machen,
> dann würde man das wenigstens noch verstehen! und pflegen
> kann man das genauso gut!
> Ich würde auch schon damit anfangen und das Ergebnis hier
> publizieren, wenn ich denn das aktuelle Modell verstehen
> würde!!!
>
> admin@... schrieb:
>  
>>> 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.
>>>
>>>      
>> Natürlich hat jedes seinen Platz in der Kiste aber von fein sortiert kann ja
>> wohl keine Rede sein. Wenn Du nun alle Äpfel haben willst, musst Du hier
>> nämlich ganze Kiste auskippen und alles sortieren.
>>
>>    
>>> 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.
>>>
>>>      
>> Absolut falsch. Eine nicht normalisierte Datenbank ist niemals eine Gute.
>>
>>    
>>>> 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;
>>> ...)
>>>
>>>      
>> Also was Du hier schreibst ist genauso kompliziert gedacht, wie die Daten nun
>> vorliegen. Ich habe keine Ahnung was Du mit Hapuri da sagen willst. Ich wüsste
>> nicht mal ob das ein Ort ist, wenn ich nicht zufällig hier dieses Beispiel
>> schon gesehen hätte. Die finnische Übersetzung von Hamburg hat meines
>> Erachtens überhaupt nichts in geodb_textdata zu suchen. Das gehört halt in
>> eine andere Tabelle mit Übersetzungen wenn das wirklich geführt werden soll.
>> Habt Ihr von allen Orten die finnische Übersetzung? Wenn nein ist eine
>> Übersetzung absolut überflüssig ja sogar dazu geeignet die Daten inkonsistent
>> zu machen.
>>
>>    
>>>>>> 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?
>>>
>>>      
>> Und was macht ihr jetzt? Ihr benutzt ein ganzen Hilfsschlüsselkonstrukt der
>> mit reinem SQL nicht zu lösen ist. In einer guten Datenbank sind das auch
>> keine Hilfstabellen sondern eine perfekt verknüpfte Datensammlung die keine
>> redundanten Daten enthält.
>>
>>
>>    
>>>>>> 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
>>>      
>> Hier genau ist das Problem. Diese Frage kann Dir keiner beantworten, da es
>> absolut nicht ersichtlich ist, wozu Du diese Gemeindeschlüssel brauchst und
>> inwiefern diese für die Gesamtheit der Daten relevant sind.
>> Hier kam auf, das kein Vorschlag gemacht wird, wie man es verbessern kann. Das
>>  ist einfach so unmöglich. Kaum einer weiß, was genau nun alles aufgenommen
>> werden soll. Es gibt hierzu keine Info. Wenn ich weiß welche Daten nun
>> wirklich in der Datenbank stehen, schreibe ich ein Datenbank Model dafür das
>> erheblich kleiner ist als das was jetzt da ist. Ich habe versucht 3 Tage lang
>> durch die Text Daten und die Datenstruktur zu blicken aber immer fand ich
>> Einträge mit denen ich einfach nichts anfangen kann. Dann habe ich einfach die
>>  locations in meine PLZ Datenbank eingespeist und alles Gehabt was ich brauchte.
>>
>> Falls mir einer die relevanten Daten aufzeigen kann veröffentliche ich hier
>> ein Datenmodel das alle Gegebenheiten berücksichtigt.
>>
>> Gruß
>>
>> Andrew
>>
>>
>>    
>>> --
>>> Mailingliste OpenGeoDB
>>> Listenadresse: opengeodb@...
>>> Informationen: http://opengeodb.de
>>> Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)
>>>      
>> ------- End of Original Message -------
>>
>>    
>
>  

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Sven Neuhaus]

Hallo,

mir erschließt sich aus der bisherigen Diskussion auch nicht der
Vorteil, den separate Tabellen für jede Art von Datentyp bringen sollen.

Es ist doch gehüpft wie gesprungen ob ich nun eine zusätzliche Spalte
habe, die den Typen festlegt, oder stattdessen eine separate Tabelle.
Im ersten Fall joine ich dann halt mehrmals mit der gleichen Tabelle, im
letzten Fall diverse unterschiedliche Tabellen.
Man könnte sich auch ein View definieren daß dann genau die Rolle der
separaten Tabelle übernimmt.

Einen Vorteil für das aktuelle Modell sehe ich aber ganz klar: Neue
Arten von Daten in die OpenGeoDB einzufügen erfordert keine Änderungen
an der Datenbankstruktur, man muß lediglich neue Typen definieren.

Gruß,
-Sven Neuhaus
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Thomas Bornhaupt]

Hallo,
> mir erschließt sich aus der bisherigen Diskussion auch nicht der
> Vorteil, den separate Tabellen für jede Art von Datentyp bringen sollen.
>
> Es ist doch gehüpft wie gesprungen ob ich nun eine zusätzliche Spalte
> habe, die den Typen festlegt, oder stattdessen eine separate Tabelle.
>  
Für das schreiben der paar Zeilen des Zugriffes ist das wohl richtig.

Aber es macht schon einen Unterschied ob von einer Datenbank nur ein
10tel, wenn nicht sogar nur 100tel, durch den Ram gejagt werden muss,
weil man die notwendigen Spalten extrahiert hat.
Ja Ja, das kann eine gute Datenbank Cachen, aber nicht jeder hat so was.

Aus Performensgründen macht es immer Sinn die Datenbank so klein wie
nötig zu machen.

Aber es steht doch jedem frei seine Tabellen aus der Ursuppe zu köcheln.

Gruß
Thomas
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Sven Neuhaus]

Thomas Bornhaupt schrieb:

>> mir erschließt sich aus der bisherigen Diskussion auch nicht der
>> Vorteil, den separate Tabellen für jede Art von Datentyp bringen sollen.
>>
>> Es ist doch gehüpft wie gesprungen ob ich nun eine zusätzliche Spalte
>> habe, die den Typen festlegt, oder stattdessen eine separate Tabelle.
>>  
> Für das schreiben der paar Zeilen des Zugriffes ist das wohl richtig.
>
> Aber es macht schon einen Unterschied ob von einer Datenbank nur ein
> 10tel, wenn nicht sogar nur 100tel, durch den Ram gejagt werden muss,
> weil man die notwendigen Spalten extrahiert hat.
> Ja Ja, das kann eine gute Datenbank Cachen, aber nicht jeder hat so was.

Da es einen Index für die Spalte "text_type" gibt dürfte sich das in der
Performance nicht allzusehr unterscheiden. Aber besser wäre natürlich
wenn das jemand mal nachmisst...
Die Tabelle ist übrigens von der Größe aber auch recht überschaubar (bei
mir unter 40MB) und dürfte deshalb in den meisten Fällen komplett im
Hauptspeicher verweilen.

Gruß,
-Sven


--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Eric-22]

Hallo liebe Leute,

ich lese hier schon seit einiger Zeit mit und habe lange versucht die
Struktur von OpenGeoDB zu verstehen, was für mich als Hobby-Programmierer
oft fast zur Verzeweiflung geführt hat. Ich verstehe inzwischen aber
einigermaßen, wie die DB funktioniert (Aufgrund meines Durchhaltevermögens).

Nachdem ich dann endlich kapiert hatte, dass ich für meine Zwecke rekursive
Abfragen durchführen muss um alle Informationen zu erhalten, die ich gerne
hätte (was mit mysql nicht geht), dämmerte es mir dann endlich welchen Zweck
die hirarchies Tabelle eigentlich hat. Leider war die Tabelle in meinem DUMP
leer, weshalb ich mir ein Skript basteln musste, welches diese erzeugt. Da
mein Skript aber eher zusammengefrickelt ist und wahrscheinlich zig Fehler
enthält hier meine erste Frage:
Frage 1: Gibt es ein fertiges PHP Skript, welches mir die Hirarchies
erzeugen kann?

Außerdem bin ich dabei die Datenbank so umzubauen, dass sie für mich gut
funktioniert. Dazu verwende ich die TAB Dateien. Zurzeit stellt sich mir
aber folgende Frage:

Frage 2: Wo ist der Unterschied zwischen den Daten innerhalb der PLZ.TAB
Datei und den PLZ Daten, die jeweils bei den Städten innerhalb der Länder
Dateien zu finden sind. Welche sind aktueller, welche umfassender?

Außerdem habe ich Schwierigkeiten die PLZ Daten aus PLZ.TAB den jeweiligen
Städten zuzuordnen. Anhand des Stadt-Namens geht es nicht (z.B. gibt es ein
Essen in Holland und ein Essen in Deutschland, welches nochdazu in der
Dhier.tab anders heißt als in der plz.tab - nämlich "Essen an der Ruhr").
Anhand der Lon und Lat ging das bei mir auch nicht, weil sich die Daten
leicht unterscheiden und außerdem manchmal Lon und Lat vertauscht ist etc. -
Auch anhand der eines abgleichs der PLZ Liste zu den Städten in den
Länderdateien mit den PLZ aus plz.tab gestaltete sich schwierig, weil die
Daten scheinbar nicht immer übereinstimmten.

Kann mir das jemand erklären?

Gruß
Eric




--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

> Frage 1: Gibt es ein fertiges PHP Skript, welches mir die Hirarchies
erzeugen kann?

Gegenfrage: Warum geht das nicht mit SQL? Fuer PHP kenne ich keines. Basierend auf den .tab gibt es eines, das genauso wie der SQL-Dump auch die hierarchies erzeugen kann.


> Frage 2: Wo ist der Unterschied zwischen den Daten innerhalb der PLZ.TAB
Datei und den PLZ Daten, die jeweils bei den Städten innerhalb der Länder
Dateien zu finden sind. Welche sind aktueller, welche umfassender?

PLZ.tab und D.tab bieten voellig unterschiedliche Daten.

PLZ.tab bietet die Daten fuer Typ 100800000, PLZ-Gebiete. Diese sind in Einzelfaellen deckungsgleich zu Staedten. Da aber eine Stadt viele PLZ-Gebiete umfassen kann oder aber ein PLZ-Gebiet viele unterschiedliche Orte abdeckt, sind es ganz andere Informationen.


> Außerdem habe ich Schwierigkeiten die PLZ Daten aus PLZ.TAB den jeweiligen
Städten zuzuordnen. Anhand des Stadt-Namens geht es nicht (z.B. gibt es ein
Essen in Holland und ein Essen in Deutschland, welches nochdazu in der
Dhier.tab anders heißt als in der plz.tab - nämlich "Essen an der Ruhr").

Du kannst mit vermutlich 100 % Uebereinstimmung aus dem Abgleich von Ortseintrag und seinen Postleitzahlen und einem PLZ-Eintrag und dessen Orts-Repraesentanten beide zusammenbringen, auch wenn sie nicht wirklich zusammengehoeren.

> Anhand der Lon und Lat ging das bei mir auch nicht, weil sich die Daten leicht unterscheiden und außerdem manchmal Lon und Lat vertauscht ist etc. -
Auch anhand der eines abgleichs der PLZ Liste zu den Städten in den
Länderdateien mit den PLZ aus plz.tab gestaltete sich schwierig, weil die
Daten scheinbar nicht immer übereinstimmten.

In der PLZ.tab reicht Laengengrad lon von 5.97 bis 14.98 und Breitengrad lat von 47.37 bis 55.02.

Eine Vertauschung der Daten kann ich daher ausschliessen. Du hast allerdings Recht, dass in DE.tab die Spalten nach lat/lon und in PLZ.tab als lon/lat vorliegen. Das ist bei jeder Konvertierung oder jedem Import frei zuordnungsfaehig.  Ist es das, was du meinst? Andernfalls solltest du unbedingt einen Fehler melden.

Schoenen Gruss
Martin

[Lucas Mengel]

Thomas Wicht schrieb:
> Den text_type gibt es um den Wert text_val eine Bedeutung zu geben,
> wenn ich Postleitzahlen abfragen möchte gebe ich den text_type dazu an.

Das habe ich schon verstanden.
Aber ich habe noch nicht so ganz verstanden, was genau gegen
ein Beispiel wie dieses hier spricht:

Tabelle:locations
id MEDIUMINT NOT NULL PRIMARY KEY
loc_id MEDIUMINT NULL
text_val VARCHAR(250) NOT NULL

Tabelle:postcodes
id MEDIUMINT AUTO_INCREMENT NOT NULL PRIMARY KEY
loc_id MEDIUMINT NULL
text_val INT(5) NOT NULL

usw.

Wir dürfen auch nicht vergessen: Je schwieriger das ganze
ist, desto weniger Leute pflegen die Datenbank, weil ja
keiner versteht, wie Daten eingeliefert werden sollen
geschweige denn wie er sie selbst einpflegen kann.
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Thomas Wicht]

Wie möchtest Du das dann weiter fortsetzen ?

Was passiert mit Stadtteilen, Bundesländern, Ländern ?

All diese Daten müssen verbunden werden, so das es einfach möglich ist

Alle Orte von Deutschland oder alle Stadtteile von Berlin
oder Ort zur plz 23554, Bundesland der plz 23554
und genau da war die hierarchies Tabelle einfach perfekt für

Ich weiß nicht weshalb diese rausgenommen wurde.

----- Original Message -----
From: "Lucas Mengel" <froschpopo@...>
To: "Mailingliste OpenGeoDB" <opengeodb@...>
Sent: Tuesday, March 18, 2008 7:25 PM
Subject: Re: [opengeodb] nur deutschland


Thomas Wicht schrieb:
> Den text_type gibt es um den Wert text_val eine Bedeutung zu geben,
> wenn ich Postleitzahlen abfragen möchte gebe ich den text_type dazu an.

Das habe ich schon verstanden.
Aber ich habe noch nicht so ganz verstanden, was genau gegen
ein Beispiel wie dieses hier spricht:

Tabelle:locations
id MEDIUMINT NOT NULL PRIMARY KEY
loc_id MEDIUMINT NULL
text_val VARCHAR(250) NOT NULL

Tabelle:postcodes
id MEDIUMINT AUTO_INCREMENT NOT NULL PRIMARY KEY
loc_id MEDIUMINT NULL
text_val INT(5) NOT NULL

usw.

Wir dürfen auch nicht vergessen: Je schwieriger das ganze
ist, desto weniger Leute pflegen die Datenbank, weil ja
keiner versteht, wie Daten eingeliefert werden sollen
geschweige denn wie er sie selbst einpflegen kann.
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

Thomas Wicht wrote:

> Wenn Ihr für alles eine extra Tabelle machen wollt, so müsst Ihr wieder x
> Tabellen
> erstellen die plz mit Stadtteilen verbinden, Stadtteile mit Orten , Orte mit
> Bundesländern , Bundesländer mit Ländern
>
> Und genau dies hatte eigentlich mal die hierachies Tabelle übernommen.

und die versagt bei Häusern in Strassen in Ortsteilen in Stadtvierteln
in Stadtbezirken...


> Ich sehe das Problem eher in der mangelten Dokumentation und fehlenden
> Beispielen. Jeder der
> das erste Mal mit der geodb arbeitet bekommt einen Anfall,

leider wahr - vor allem wenn Doku und Version nicht mehr zusammenpassen.


--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

Thomas Wicht wrote:

> und genau da war die hierarchies Tabelle einfach perfekt für
>
> Ich weiß nicht weshalb diese rausgenommen wurde.

Wurde oft genug geschrieben:
- redundant
- pflegeaufwendig
- statisch zu begrenzt für zukünftige Ergänzungen



--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Stephan Schuster]

Hallo Robo,

> >> > Du hast hier schon mehrfach behauptet, bei der gegenwärtigen Datenbank-Struktur
> >> > wäre von Normalisierung keine Spur, mich würde dazu mal interessieren, gegen
> >> > welche Normalform Deiner Meinung nach verstoßen wird?
> >>
> >> geodb_textdata ist nicht atomar. Andere Tabellen auch nicht.
> >
> > Das ist eine Behauptung. Wo ist ein Beleg oder ein Beispiel? Welches
> > Attribut enthält Deiner Meinung nach einen nichtatomaren Wertebereich?
>
> Der Knackpunkt ist für mich geodb_textdata.text_type. Dieses Attribut
> wäre überflüssig, würde man nicht verschiedene Datenarten in eine
> Tabelle reinstopfen.

Das ist eine Frage der Sichtweise. Was du als verschiedene Datenarten
wahrnimmst, interpretieren andere als Daten die als Text zu
interpretieren sind, und bevor Du monierst, es stehen auch Zahlen drin:
Dir als Programmierer ist Typisierung sicher ein Begriff.

Wenn Du möchtest, kannst Du geodb_textdata.text_type auch als
Fremdschlüssel aus der Tabelle geodb_type_names sehen, das kommt deinem
Verständnis von Datenbank-Modellen und Normalisierung sicher näher. Die
Daten dazu findest Du in opengeodb-end.sql, die type_id entspricht dem
Wert von text_type und hat, wenn schon keinen PRIMARY so zumindest einen
UNIQUE-Key.
[...]

> > Weiterhin erwecken deine Äußerungen den Eindruck, dass du dich mal
> > -ähnlich oberflächlich wie mit der opengeodb- mit Datenbank-Normalisierung
> > beschäftigt hast und bei jeder Gelegenheit damit um dich wirfst.
> > Normalisierung ist ein Konzept zur Vermeidung von Redundanzen und
> > Inkonsistenzen, keine Religion.
>
> Und was ist geodb_textdata.text_type? Ein Konzept zur Erzeugung von
> Redundanzen?

Welche Daten sind deiner Meinung nach redundant vorhanden? Wo ist
text_type nicht atomar? Belege deine Behauptungen bitte mit Beispielen!
Dann kann man darüber diskutieren.
[...]

> > Beim Entwickeln einer alternativen Struktur, die Art und Umfang der
> > Information aufnehmen kann, die die opengeodb bietet hättest Du schnell
> > gemerkt, dass eine "vereinfachte" Form wie sie dir vorschwebt dies nicht
> > leisten kann.
>
> Ich kann mir einfach nicht vorstellen, dass es nicht möglich sein soll,
> die Opengeodb so zu strukturieren, dass die Struktur verständlicher wird.

Probier es aus. Bitte. Du hast alle Daten zur Verfügung. Ich hoffe, dass
nicht alle Dinge davon abhängen, ob du dir sie vorstellen kannst.

> > Versuche einfach mal in deiner vereinfachten Form die
> > verschiedenen Hierarchie-Ebenen in unterschiedlichen Staaten oder
> > Bundesländern abzubilden.
>
> Das kann ich nicht, weil ich die Verwaltungsgliederung in anderen
> Staaten nicht kenne.

Und weil du diese nicht kennst und keine Lust hast dich zu informieren,
sollen alle anderen darauf verzichten? Hast du nicht erst kürzlich
darauf hingewiesen, dass die opengeodb möglicherweise zukünftig andere
Länder aufnimmt?

> Ich hätte wohl besser schreiben sollen:
> Flexibility by accepting obscurity.
>
> Oder anders gesagt: Was nutzt die ganze Flexibilität, wenn kaum einer
> durchblickt?

Weil du nicht durchblickst, heisst das nicht, dass dies auch bei allen
anderen so ist. Was meinst du, wieviele Leute sich hier die Daten holen,
nachfragen, wenn sie was nicht verstehen und wieder gehen. Das ist
sicher die Mehrheit, auch wenn Leute wie du natürlich hier mehr traffic
erzeugen.

Du bist wie jemand, der zum Motorrad-Händler geht und sagt, "das was ihr
hier anbietet ist doch totaler Mist, macht doch mal ein Dach drauf und
noch zwei Räder dran und baut bequemere Sitze ein, so kann man das doch
nicht benutzen". Kauf dir einfach ein Auto, oder die Daten von der Post.
Vielleicht entsprechen die deinen Erwartungen

[...]

>
> > Du mißverstehst die Motivation hinter opengeodb, hier werden Geodaten
> > gesammelt, bearbeitet und zur Verfügung gestellt. Und dafür ist die
> > bestehende Datenbank-Struktur entwickelt worden. Du willst die Struktur
> > auf Deinen eingeschränkten Bedarf (Webanwendung o.ä.) hin optimieren,
> > das kannst Du gerne für dich tun.
>
> Nein, das siehst du falsch. Ich bin der Meinung, die Datenstruktur
> sollte durchaus felexibel, aber trotzdem verständlich sein. Klar sollte
> jeder die Daten, die er benötigt, in eine dafür passende Struktur
> überführen. Und eine etwas verständlichere Struktur der Rohdaten wäre
> dafür sicher nicht von Nachteil.

Dann stelle diese "verständlichere Struktur" hier vor. Einzige Prämisse:
kein Informationsverlust, soweit normalisiert wie praktikabel / sinnvoll.
Niemand hier hängt sein Herz an die bestehende Struktur, sie ist
lediglich ein Vehikel, das die Daten bereithält.

Dir schwebt ein "klassisches" Datenbank-Modell vor, mit einer
Haupttabelle z.B. locations und alle zugehörigen Daten (z.B.
Postleitzahlen, Bundesland, Landkreis etc.) als Fremdschlüssel-referenzierte
Daten in eigenen Tabellen. Selbst wenn Du nicht weisst, wie die
Hierarchie-Strukturen woanders aufgebaut sind, wirst Du wissen, dass es
Staaten gibt, die keine Bundesländer besitzen, wie gehst Du damit um?

Egal, wie du deine (angeblich) einfachere Struktur auch aufbaust, du
wirst mit deinen Tabellen immer vor Problemen stehen, wenn Daten
dazukommen oder wegfallen. Möchtest Du beispielsweise die
durchschnittliche Schuhgröße der Männer über 40 mit erfassen, benötigst
Du:

- eine zusätzliche Tabelle für die Schuhgrößen
- einen Fremdschlüssel oder (bei n:m-Relationen) sogar eine zusätzliche
  Transfer-Tabelle mit den Zuordnungen.
 
Möchtest Du die Schuhgrößen neben der in de gebräuchlichen Schreibweise
auch in Mondopoint erfassen musst Du ein weiteres Feld an deine
Schuhgrößen-Tabelle anhängen (oder noch eine Tabelle erzeugen). Kommt
jemand und möchte auch amerikanische Schreibweise wiederholt sich der
Vorgang.

Oder versuche das ganze mit der Erfassung von Postleitzahlen, die
Postfächern zugeordnet sind. Wie gehst du vor?

Bei jeder Änderung der zu erfassenden Daten musst Du deine
Datenbank-Struktur ändern, jeder Nutzer deines Modells muss diese
Änderungen spätestens beim Update seiner Daten nachvollziehen. Dabei
riskierst Du immer, dass bestehende Anwendungen nicht mehr funktionieren.

In der jetzigen Struktur musst Du lediglich einen neuen Typ definieren
und kannst mit der Dateneingabe starten. Alle Anwendungen laufen weiter
wie bisher.

Der Aufwand nur benötigte Teildaten aus deiner Datenbank zu extrahieren,
ist wesentlich höher, als jetzt.

Und wo ist der Unterschied, ob Du 5x geodb_textdata mit entsprechendem Alias
joinst oder 5 Tabellen, mit unterschiedlichen Namen? Hast Du nicht erst
Tips mit sprechenden Aliasen gegeben?

Die jetzige Struktur ist aus der Erkenntnis entstanden, dass die, die du
favorisierst, den anfallenden Daten nicht gerecht wird, denn eine solche
Struktur war ursprünglich vorhanden. Ich schick Dir gerne mal einen Dump
der opengeodb 0.1.3. Und ich kann dir versichern dass Normalisierung
bei der Entwicklung der jetzigen Struktur auch ein großes Thema war. Und
wenn du wieder behaupten willst, das Schema wäre nicht normalisiert,
bring Belege, wenn du weiter ernst genommen werden willst. (Wenn Du dich
an fehlenden Primärschlüsseln aufhängen willst: Ein simples ALTER TABLE
erzeugt sie dir, bei der jetzigen Verwaltung der Daten sind diese nicht
notwendig, auch wenn sie sicher zur eindeutigen Adressierung
wünschenswert sind.)
 
[...]
> Mein Problem liegt darin, dass es viele Leute gibt, die einfach nicht
> durchblicken. Das kann man leicht erkennen, wenn man die Postings hier
> ein wenig mitverfolgt.

Die Bereitschaft zu lernen und sich mit den Dingen auseinanderzusetzen
sind nun einmal Vorraussetzung hier. Lesen lernen ist auch schwer und
die Welt wäre ärmer, wenn man auf 80% der Worte verzichten würde, weil
nur 20% sie benutzen wollen.

Hier steht nirgendwo ein Schild "Die Opengeodb bietet einfach verständliche
Daten für eine Umkreissuche", man kann die Daten dafür nutzen, aber auch
ganz andere Dinge damit machen. Wer etwas umsonst haben will, muss halt
seinen Grips etwas anstrengen.

> Und mein Problem liegt darin, dass ich meine eigenen SQL-Statements, die
> ich mir mal vor anderthalb Jahren zusammengeschustert habe, um die Daten
> zu extrahieren, jetzt selbst auf Anhieb nicht mehr verstehe.

Und das ist ein Fehler der opengeodb? Du solltest dazu übergehen, deinen
Code besser zu kommentieren / dokumentieren.
 
> > Niemand hier glaubt, dass die Opengeodb in der jetzigen Form perfekt ist
> > und jeder der helfen will sie zu verbessern ist hier gern gesehen. Dazu
> > gehört aber die Bereitschaft etwas mehr einzubringen, als ein paar
> > abwertende Statements.
>
> Da kann ich leider nur sehr begrenzt beitragen, weil mir die
> Voraussetzungen, insbesondre was Verwaltungsgliederungen anderer Staaten
> anbelangt, nicht bekannt sind.

Darum geht es nicht. Du könntest -mit etwas gutem Willen- selbst prüfen,
ob das, was du hier anregst, sinnvoll ist und ob die Kritik die du übst
berechtigt ist. Wenn Du dazu nicht bereit bist, brauchen wir nicht
weiter zu diskutieren, schade um die Zeit.

Und nein: "ist mir zu kompliziert" ist kein Argument!

Gruß
Stephan

--
Stephan Schuster <stephan.s@...>

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Stephan Schuster]

> So sehe ich das auch!
> Ich habe auch nie verstanden, warum es diese text_type
> überhaupt gibt. Man könnte geenauso gut tabellen machen,
> dann würde man das wenigstens noch verstehen! und pflegen
> kann man das genauso gut!

Nein, der Vorzug der aktuellen Struktur ist, dass die Erfassung weiterer
Datentypen durch hinzufügen eines text_types möglich ist, ohne die
Datenbank-Struktur zu ändern.

Füge in deinem Modell beispielsweise die Erfassung der Geburtenrate pro
Jahr hinzu und du siehst was ich meine. Die jetzige Struktur ist bereits
ausreichend, um die Information aufzunehmen, es genügt ein Eintrag in
der Tabelle geodb_type_names und man kann loslegen die Daten zu erfassen.

> Ich würde auch schon damit anfangen und das Ergebnis hier
> publizieren, wenn ich denn das aktuelle Modell verstehen
> würde!!!

Das ist im Prinzip ganz einfach: Alle Daten sind zentral über die loc_id
verknüpft, der Wert von text_type (in Tabelle geodb_textdata) beschreibt
als Fremdschlüssel der Tabelle geodb_type_names die Bedeutung des Wertes.

So erhälst Du mit der Abfrage

SELECT gtn.name, gt.text_val  
FROM geodb_textdata  AS gt
LEFT JOIN geodb_type_names AS gtn ON gt.text_type = gtn.type_id
WHERE loc_id = 21855

alle Informationen zu Oberammergau, die als Text interpretiert werden
sollten. Analog dazu liefert

SELECT gtn.name, gi.int_val
FROM geodb_intdata AS gi
LEFT JOIN geodb_type_names AS gtn ON gi.int_type = gtn.type_id
WHERE loc_id = 21855

alle Informationen, die als Integer-Wert interpretiert werden sollten,
in diesem Fall die Einwohnerzahl. Das ganze kannst Du noch mit
geodb_coordinates und geodb_floatdata machen und hast alle Informationen
die in der Datenbank zur loc_id von Oberammergau vorhanden sind.

Dabei solltest Du noch wissen, von welchem Typ der Eintrag in der
geodb_locations ist.

SELECT gtn.type_id, gtn.name, COUNT(*) AS amount
FROM geodb_locations AS gl
LEFT JOIN geodb_type_names AS gtn ON gl.loc_type = gtn.type_id
GROUP BY gl.loc_type

liefert dir eine Übersicht über die vorhandenen Location-Typen.
Oberammergau ist eine "politische Gliederung"

Über entsprechende Joins kannst Du dir die Daten für deine Zwecke
aufbereiten. Willst Du zum Beispiel eine Tabelle mit Landkreisen
erstellen, erstellst du dir eine Tabelle (geodb_landkreise) und einem
Feld für den Landkreisnamen (lkrs_name) und führst die folgende Query
aus:

INSERT INTO geodb_landkreise (lkrs_name)
SELECT lkrs_name.text_val
FROM geodb_locations AS gl
LEFT JOIN geodb_textdata AS lkrs_name ON gl.loc_id = lkrs_name.loc_id
WHERE gl.loc_type =100500000 /* ID für Landkreis */
AND lkrs_name.text_type =500100000 /* ID für Name */

Damit hast Du alle Landkreisnamen eingefügt. Möchtest Du weitere
Informationen zum Landkreis hinzufügen, musst Du eben weitere Joins auf
die geodb_textdata mit dem passenden text_type durchführen.
Z.B. KFZ-Kennzeichen, type_id bzw.text_type 500500000:

INSERT INTO geodb_landkreise (lkrs_name, lkrs_kfz)
SELECT lkrs_name.text_val AS landkreis, kfz_name.text_val AS kfz
FROM geodb_locations AS gl
LEFT JOIN geodb_textdata AS lkrs_name ON gl.loc_id = lkrs_name.loc_id
LEFT JOIN geodb_textdata AS kfz_name ON gl.loc_id = kfz_name.loc_id
WHERE gl.loc_type =100500000 /* ID für Landkreis */
AND lkrs_name.text_type =500100000 /* ID für Name */
AND kfz_name.text_type =500500000 /* ID für KFZ-Kennzeichen */

Analog funktioniert das auch mit den anderen Tabellen für Koordinaten, int
und float Werte.

Mit diesen Informationen solltest du dir nun deine eigene Datenbank mit
einem dir passenden Schema zusammenbauen können.

Gruß
Stephan

--
Stephan Schuster <stephan.s@...>

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Lucas Mengel]

Ja Okay, das verstehe ich.
Aber es wäre trotzdem cool, wenn hierarchies dann gefüllt
ausgeliefert wird. Weil ich habe echt keine Ahnung, wie ich
diese selber füllen muss um z.B. alle deutschen
Postleitzahlen auszugeben.
Die Antwort "dann musst du alle Ebenen durchlaufen" bringt
mir herzlich wenig.



Stephan S schrieb:

>> So sehe ich das auch!
>> Ich habe auch nie verstanden, warum es diese text_type
>> überhaupt gibt. Man könnte geenauso gut tabellen machen,
>> dann würde man das wenigstens noch verstehen! und pflegen
>> kann man das genauso gut!
>
> Nein, der Vorzug der aktuellen Struktur ist, dass die Erfassung weiterer
> Datentypen durch hinzufügen eines text_types möglich ist, ohne die
> Datenbank-Struktur zu ändern.
>
> Füge in deinem Modell beispielsweise die Erfassung der Geburtenrate pro
> Jahr hinzu und du siehst was ich meine. Die jetzige Struktur ist bereits
> ausreichend, um die Information aufzunehmen, es genügt ein Eintrag in
> der Tabelle geodb_type_names und man kann loslegen die Daten zu erfassen.
>
>> Ich würde auch schon damit anfangen und das Ergebnis hier
>> publizieren, wenn ich denn das aktuelle Modell verstehen
>> würde!!!
>
> Das ist im Prinzip ganz einfach: Alle Daten sind zentral über die loc_id
> verknüpft, der Wert von text_type (in Tabelle geodb_textdata) beschreibt
> als Fremdschlüssel der Tabelle geodb_type_names die Bedeutung des Wertes.
>
> So erhälst Du mit der Abfrage
>
> SELECT gtn.name, gt.text_val  
> FROM geodb_textdata  AS gt
> LEFT JOIN geodb_type_names AS gtn ON gt.text_type = gtn.type_id
> WHERE loc_id = 21855
>
> alle Informationen zu Oberammergau, die als Text interpretiert werden
> sollten. Analog dazu liefert
>
> SELECT gtn.name, gi.int_val
> FROM geodb_intdata AS gi
> LEFT JOIN geodb_type_names AS gtn ON gi.int_type = gtn.type_id
> WHERE loc_id = 21855
>
> alle Informationen, die als Integer-Wert interpretiert werden sollten,
> in diesem Fall die Einwohnerzahl. Das ganze kannst Du noch mit
> geodb_coordinates und geodb_floatdata machen und hast alle Informationen
> die in der Datenbank zur loc_id von Oberammergau vorhanden sind.
>
> Dabei solltest Du noch wissen, von welchem Typ der Eintrag in der
> geodb_locations ist.
>
> SELECT gtn.type_id, gtn.name, COUNT(*) AS amount
> FROM geodb_locations AS gl
> LEFT JOIN geodb_type_names AS gtn ON gl.loc_type = gtn.type_id
> GROUP BY gl.loc_type
>
> liefert dir eine Übersicht über die vorhandenen Location-Typen.
> Oberammergau ist eine "politische Gliederung"
>
> Über entsprechende Joins kannst Du dir die Daten für deine Zwecke
> aufbereiten. Willst Du zum Beispiel eine Tabelle mit Landkreisen
> erstellen, erstellst du dir eine Tabelle (geodb_landkreise) und einem
> Feld für den Landkreisnamen (lkrs_name) und führst die folgende Query
> aus:
>
> INSERT INTO geodb_landkreise (lkrs_name)
> SELECT lkrs_name.text_val
> FROM geodb_locations AS gl
> LEFT JOIN geodb_textdata AS lkrs_name ON gl.loc_id = lkrs_name.loc_id
> WHERE gl.loc_type =100500000 /* ID für Landkreis */
> AND lkrs_name.text_type =500100000 /* ID für Name */
>
> Damit hast Du alle Landkreisnamen eingefügt. Möchtest Du weitere
> Informationen zum Landkreis hinzufügen, musst Du eben weitere Joins auf
> die geodb_textdata mit dem passenden text_type durchführen.
> Z.B. KFZ-Kennzeichen, type_id bzw.text_type 500500000:
>
> INSERT INTO geodb_landkreise (lkrs_name, lkrs_kfz)
> SELECT lkrs_name.text_val AS landkreis, kfz_name.text_val AS kfz
> FROM geodb_locations AS gl
> LEFT JOIN geodb_textdata AS lkrs_name ON gl.loc_id = lkrs_name.loc_id
> LEFT JOIN geodb_textdata AS kfz_name ON gl.loc_id = kfz_name.loc_id
> WHERE gl.loc_type =100500000 /* ID für Landkreis */
> AND lkrs_name.text_type =500100000 /* ID für Name */
> AND kfz_name.text_type =500500000 /* ID für KFZ-Kennzeichen */
>
> Analog funktioniert das auch mit den anderen Tabellen für Koordinaten, int
> und float Werte.
>
> Mit diesen Informationen solltest du dir nun deine eigene Datenbank mit
> einem dir passenden Schema zusammenbauen können.
>
> Gruß
> Stephan
>

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Gemander, Ronny]

Ich bekomms immer noch nicht hin.

Ich hab:

SELECT text.text_val as plz, coord.lat as lat, coord.lon as lon
FROM geodb_textdata as text
LEFT JOIN geodb_coordinates as coord
ON(text.loc_id = coord.loc_id)
WHERE text.loc_id IN (SELECT loc_id FROM geodb_textval WHERE
geodb_textval.text_type = 50030000)
AND text.text_type = 50030000
ORDER BY plz

die liefert mir aber zu jeder Postleitzahl mindestens 3 Datensätze. Wie
bekomm ich denn nun daraus einen eindeutigen? Ich weiss das lat und lon
unterschiedliche Werte haben, aber der erste (mit den kürzeren lat, lon
Einträgen) würde mir für jede PLZ reichen. DISTINCT ist irgendwie nicht
so ganz das was ich brauch.

Gruß, Ronny

Stephan S schrieb:

>> [...]
>>
>> Analog funktioniert das auch mit den anderen Tabellen für Koordinaten, int
>> und float Werte.
>>
>> Mit diesen Informationen solltest du dir nun deine eigene Datenbank mit
>> einem dir passenden Schema zusammenbauen können.
>>
>> Gruß
>> Stephan
>>
>>    
>
>  

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)