[opengeodb] nur deutschland

[Robert Böck]

Hallo Stephan,

Stephan S wrote:

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

Wenn man eine Datenbank hat, in der es um Geokoordinaten geht, die mit
Orten, Postleitzahlen und was weiß ich verknüpft sind, dann macht es
meiner Meinung nach schon Sinn, einen Ort auch als Ort zu sehen, und
nicht nur als schnöden Datensatz von Typ "Text".

> und bevor Du monierst, es stehen auch Zahlen drin:
> Dir als Programmierer ist Typisierung sicher ein Begriff. 

Dann könnte man die Koordinaten ja auch noch mit in die Tabelle
reinpacken. Und den ganzen Rest auch. Mit Typecasting ist das ja alles
kein Problem. Und spart nochmal ein paar Tabellen.

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

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

geodb_textdata.text_type selbst ist redundant, weil es überflüssig ist,
wenn man die Daten sauber trennt.

> Wo ist text_type nicht atomar? Belege deine Behauptungen bitte mit Beispielen!

Wer behauptet das?

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

Mit den Daten, die jetzt in der Opengeodb drin sind, geht es. Und wenn
man einen zusätzlichen Datentyp aufnehmen will, muss man eben eine neue
Tabelle dazubauen.

Wenn man ein Datenmodell entwickelt, muss man sich eben _vorher_ darüber
Gedanken machen, welche Daten dieses Modell aufnehmen können soll. Wenn
man ein universelles Datenmodell baut, also praktisch eine eierlegende
Wollmilchsau, hat man zwar den Vorteil, dass man sich erst hinterher
Gedanken darüber machen muss, welche Daten man denn nun aufnehmen will,
aber man hat auch den Nachteil, dass das Datenmodell schnell beliebig
kompliziert und unverständlich 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.
> 
> Und weil du diese nicht kennst und keine Lust hast dich zu informieren,
> sollen alle anderen darauf verzichten?

Wer behauptet das?

> Hast du nicht erst kürzlich
> darauf hingewiesen, dass die opengeodb möglicherweise zukünftig andere
> Länder aufnimmt?

Das war nicht ich.

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

Schon allein die Tatsache, dass viele nachfragen, weil sie etwas nicht
verstehen, zeigt doch, wie kompliziert die ganze Geschichte ist.

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

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

So in etwa.

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

Ich hänge die nächste Verwaltungsebene einfach eine Ebene höher ein. Es
muss natürlich dann dokumentiert sein oder noch besser eine Tabelle
geben, in der die Verwaltungsstrukturen für jedes Land gespeichert sind.

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

Ich habe doch schon geschrieben, dass man sich _vorher_ Gedanken machen
sollte, was alles an Daten rein soll, bevor man eine Datenstruktur baut.
Und was ist so schlimm daran, eine neue Tabelle einzufügen?

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

Wenn man diese Information haben will, braucht eben die Postleitzahl
noch ein weiteres Feld, in dem steht, ob sie zu einem Postfach gehört
oder nicht.

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

Nicht unbedingt. Wenn bestehende Tabellen nicht geändert werden und nur
neue hinzukommen, sehe ich kein Problem.

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

Ob ich einen neuen Typ definiere oder eine neue Tabelle einfüge, macht
doch für die Abwärtskompatiblität keinen Unterschied.

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

Warum?

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

Vielen Dank, aber ich habe die 0.2.4d im 0.1.3-Layout vorliegen.

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.

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.

Um nun wieder die Kurve zu kriegen: Die Struktur der Opengeodb kommt mir
ein bisschen vor wie Ungarisch ...

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

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.

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

> Wenn Du dazu nicht bereit bist, brauchen wir nicht
> weiter zu diskutieren, schade um die Zeit.

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

cu, Robo :)