[opengeodb] nur deutschland

[Stephan Schuster]

Hallo Robo,
> 
> Stephan S wrote:
[...]
> > 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.
> 
> Das ändert aber nichts daran, dass geodb_textdata.text_type redundant
> ist. Jedenfalls meiner Auffassung nach.

??? Fremdschlüssel sind nahezu immer redundant vorhanden, das liegt in
der Natur der Sache. Der Fremdschlüssel für den Landkreis Pinneberg
würde sich in deiner Tabelle mit Gemeinden ca. 49 mal finden. Lies mal
http://de.wikipedia.org/wiki/Redundanz_%28Information%29
den Abschnitt "Datenbanken und Datenstrukturen"

> > Welche Daten sind deiner Meinung nach redundant vorhanden? 
> 
> geodb_textdata.text_type selbst ist redundant, weil es überflüssig ist,
> wenn man die Daten sauber trennt.

Meinst Du mit "redundant" etwa überflüssig? Das würde einiges erklären.
 
> > Wo ist text_type nicht atomar? Belege deine Behauptungen bitte mit Beispielen!
> 
> Wer behauptet das?

Du. Hier:
>> >> geodb_textdata ist nicht atomar. Andere Tabellen auch nicht.
 Du hast dich sogar selbst zitiert. Einen Beleg hast Du noch nicht
 geliefert...
 
 [...]

> >> > 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?
> 
> Wer behauptet das?

Das impliziert dein Datenmodell,  das jetzige nimmt diese Information
problemlos auf.
 
 [...]
 
> Schon allein die Tatsache, dass viele nachfragen, weil sie etwas nicht
> verstehen, zeigt doch, wie kompliziert die ganze Geschichte ist.

Hat jemand behauptet, es wäre nicht kompliziert? Wer sich mit komplexen
Dingen beschäftigt muss nunmal in Kauf nehmen, dass man etwas
investieren muss.
 
> >> 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.
> 
> Ich habe aber keine in der Schublade liegen.

Du möchtest also dass andere die Arbeit für dich erledigen, so wie du
dir das vorstellst? Du erwartest dass die Leute die die Daten pflegen
dir zuliebe eine Struktur verwenden, die sie für unsinnig halten, da man
sich ständig mit der Struktur, statt mit den Daten beschäftigt? Ohne
dass du schlüssige Argumente für deine Variante lieferst? "Ist für mich
verständlicher" ist kein Argument in diesem Sinn.
[...]
> Ich habe doch schon geschrieben, dass man sich _vorher_ Gedanken machen
> sollte, was alles an Daten rein soll, bevor man eine Datenstruktur baut.

Die Erfahrung der letzten Jahre hat gezeigt, dass die Anforderungen bei
Geoinformationen sich mit den wechselnden Nutzern ändern. Die jetzige
Struktur trägt dem Rechnung.

> Und was ist so schlimm daran, eine neue Tabelle einzufügen?

Man ändert die Struktur und mit jedem Update müssen nicht nur die
Nutzdaten aktualisiert werden, sondern die komplette Struktur. Und du
erhöhst den Aufwand eine Dokumentation zu pflegen, usw...
 [...]
> 
> Ob ich einen neuen Typ definiere oder eine neue Tabelle einfüge, macht
> doch für die Abwärtskompatiblität keinen Unterschied.

Doch, im einen Fall änderst Du nur Daten, im anderen die Struktur und
Daten. Importiere ich die Daten aus deiner SQL-Datenbank muss ich meine
Struktur ebenfalls anpassen, da evtl Fremdschlüssel-Attribute nicht
vorhanden sind.

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

Vergleiche beide Varianten und denk selbst nach.

> > 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?
> 
> Wenn ich 5 x geodb_textdata joine muss die DB diese Tabelle 5 x laden.
> Wenn ich aber die geodb_textdata in 5 Tabellen aufteile und diese 5
> einzelnen Tabellen joine, muss die DB nur ein Fünftel der Datenmenge
> laden. Ungefähr jedenfalls. Für die Datenbank macht das einen großen
> Unterschied; umso mehr, je größer die Datenmenge wird.

Die Datenbank ist auf Flexibilität bei Erfassung und Pflege der Daten
ausgelegt, nicht auf möglichst performante Abfragen. Jeder, der ein
bisschen mitdenkt, erzeugt sich die Struktur die er braucht. Das ist dir
hier schon mehrfach erläutert worden.

[..]

> Und auch wenn es dir wahrscheinlich nicht gefällt, muss ich sagen, dass
> die Tabelle geodb_locations hochgradig redundante Daten enthält. Was
> soll bitte daran normalisiert sein, wenn immer wieder "Landkreis xyz"
> drinsteht? Die Landkreise gehören in eine eigene Tabelle und über
> Fremdschlüssel in der geodb_locations referenziert. Und nicht nur die
> Landkreise.

Wieder eine Behauptung, ohne  Beleg oder Beispiel. Wo steht immer wieder
""Landkreis xyz"? Oder nenn mir die Normalform, gegen die
geodb_locations verstösst?

1. NF: alle Attribute sind atomar, keines ist weiter zerlegbar.
2. NF: es existieren nur Schlüsselkandidaten, damit liegt automatisch
            die 2.NF vor
3. NF: gleicher Sachverhalt wie bei 2.NF

Du schwafelst, und weisst nicht wirklich was Normalisierung ist.

Konkret:

SELECT DISTINCT *
FROM geodb_locations
WHERE loc_type =100500000

liefert mir 440 Einträge vom Typ Landkreis. Wo siehst Du hier Redundanz.
Zeig mit bitte einen einzigen redundanten Datensatz!

> Allerdings ist dieses Layout in der Tat erheblich weniger kompliziert.
> 
> >> 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.
> 
> Dann empfehle ich dir, Ungarisch zu lernen. Ich kann es nicht, aber ich
> weiß, dass es als Erwachsener extrem schwierig bis nahezu unmöglich ist.
> Ich kenne eine Ungarin, die mir gesagt hat, dass man es, wenn man es
> nicht schon von frühester Kindheit an gelernt hat, praktisch nicht mehr
> lernen kann. Da hilft dir die Bereitschaft, lernen zu wollen, auch nur
> begrenzt weiter.
> 
> Finnisch soll im Übrigen ähnlich schwierig sein.

Du möchtest also, dass die Ungarn und die Finnen ihre Sprache
vereinfachen, damit du sie leichter lernen kannst? Im Ernst? Ich bin
beeindruckt von soviel Egozentrik.

[...]

> Wie soll ich meinen Code oder besser meine SQL-Statements vernünftig
> kommentieren, wenn die Opengeodb an sich schon schlecht dokumentiert
> ist? Ich habe mir die SQL-Abfragen seinerzeit in mühevoller Kleinarbeit
> anhand von Beispielen, die ich bei Sourceforge gefunden habe,
> zusammengezimmert.

Versuche zu verstehen und komplettiere bzw. berichtige die Dokumentation
und hilf das Projekt zu verbessern. Davon lebt das Projekt. OpenGeoDB
ist kein Produkt, das du gekauft hast und es gibt keine Support-Garantie
die du in Anspruch nehmen kannst.

> >> 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.
> 
> Ob irgendetwas sinnvoll oder berechtigt ist, ist immer eine Frage der
> Sichtweise.

Wiederholte Kritik, die ohne die Bereitschaft geäußert wird, sich mit
dem kritisierten Objekt auch in der Tiefe zu beschäftigen ist niemals
berechtigt, das ist keine Frage der Sichtweise.

Du kommst hier ständig mit Redundanz und Normalisierung, ohne einen
einzigen konkreten Datensatz anzuführen, der deine Behauptungen
untermauert.

> Ich bin der Meinung, eine weitere Diskussion bringt uns nicht weiter,
> weil die Standpunkte einfach zu verschieden sind.

Dir stehen die Daten der OpenGeoDB frei zur Verfügung, mach damit was
dir sinnvoll erscheint. Falls Du etwas zustande bringst, was Deiner
Meinung nach besser ist als der Status Quo kannst Du das ja
veröffentlichen. Aber erwarte nicht, dass andere die Arbeit für dich
erledigen.

Gruß
Stephan