[opengeodb] nur deutschland

[Peter Wendorff]

Hallo Robert.

Robert Böck schrieb:
>> 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.
>   
Und dann willst Du nach Städten suchen - wie machst Du das?
Nach konstanter Ebene suchen geht nicht - denn je nachdem, wo die Stadt 
liegt, fehlen ja übergeordnete Ebenen - oder eben nicht, und Städte sind 
auf unterschiedlichen Ebenen eingeordnet.
Mit den Teil-Von-Beziehungen in Reinform ginge das noch, aber damit ist 
die geodb_hierarchies wieder nicht dabei, die so viele unbedingt haben 
wollen (ich bin mir grade nicht sicher, ob Du auch zu der Fraktion 
gehörst, die die hierarchies haben wollten).

Um bei deinem Ansatz jedenfalls Staats- oder auch Landesgrenzen (auch 
unter den Bundesländern gibt es Unterschiede wie z.B. fehlende 
Regierungsbezirke etc) zu ignorieren, brauchst Du entweder wieder einen 
Typ innerhalb der Einträge, oder die Abfragen werden beliebig komplex, 
weil alle Eigenheiten einzelner Regionen in der Anwendungsprogrammierung 
berücksichtigt werden müssen.
> Ich habe doch schon geschrieben, dass man sich _vorher_ Gedanken machen
> sollte, was alles an Daten rein soll, bevor man eine Datenstruktur baut.
>   
Diese Aussage lasse ich für einige Softwareentwicklungen zum Teil 
gelten, nicht aber für ein Projekt wie die opengeodb.
Bei einigen geisterten bei diesem Projekt sicherlich von Anfang an Ideen 
im Kopf herum, wie man Straßen, Häuser, Einwohnerzahlen, 
Altersstrukturen, Arbeitslosenzahlen, Verkehrsanbindungen oder sonst 
irgendwas mit einbauen könnte - vielleicht auch die Schuhgrößen, die an 
anderer Stelle hier genannt worden sind.
Dein Vorschlag wäre gewesen: Bastelt eine Datenbank mit ca 200 Tabellen, 
die das alles abbilden kann, und lasst 180 davon leer.
Klar - hätte man machen können, aber die Fragen wären nicht weniger 
geworden, nur anders gelagert: Welche Tabellen brauche ich denn jetzt?
Mit der aktuellen Struktur lassen sich verschiedenartigste Daten recht 
gut verwalten und auch auslesen - wenn man weiß, wie es funktioniert.
> Und was ist so schlimm daran, eine neue Tabelle einzufügen?
>   
Nicht mehr oder weniger, als alles in eine zu packen, was gleichartig 
behandelt werden kann: Bisher musst Du den Quelltext anpassen, um z.B. 
weitere types zu unterstützen, mit neuen Tabellen eben auch.
>> 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.
>   
Wenn nur neue Typen hinzukommen, sehe ich aber auch 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.
>   
Das ist richtig, wenn man deinen Vorschlag als Struktur umgesetzt hat, 
die Umstellung würde aber eben einen großen Umbruch geben, der plötzlich 
sehr viele Anwendungen inkompatibel machen würde.
Eine Sache kannst Du mit neuen Tabellen aber nicht leisten, was die 
aktuelle Struktur kann:
Wenn du eine Tabelle mit den Typnamen hast, die den Typkonstanten 
sprechende Namen bzw. Beschreibungen zuordnet, so kannst Du in einer 
Anwendung direkt auch neue Datentypen mit unterstützen - zumindest in 
der Ausgabe.
Wenn ich zu einer locid alle Informationen suche, muss ich eben nur in 
geodb_textdata nach allen Einträgen suchen, die diese locid tragen, dazu 
ein Join zwischen dem Typ und der Typentabelle, und ich kann direkt die 
Beschreibung des Eintrags und den Wert selbst ausgeben, für den Benutzer 
vielleicht ganz nützlich, obwohl ich es bei der Programmierung nicht 
berücksichtigt habe.
>> 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.
>   
Rechnen wir mal durch...
Die gesamte opengeodb hat bei mir im Moment eine Größe von ca 100 MB, 
davon entfallen ca 70% auf die geodb_textdata.
Häufigste Anwendungen für geodb_textdata sind:
- ich habe eine locid und brauche spezifische Textdaten dazu, also joine 
ich eine Teilmenge. Jedes Datenbank-Managementsystem, was den Namen 
sinnvoll verdient (ich hoffe, ich trete Martin mit dieser Aussage jetzt 
nicht auf den Schlips, weil er auf den Textdateien arbeitet), benutzt 
für diesen Join die entsprechenden Indizes - bei mir existiert (direkt 
eingespielt, keine Änderungen am heruntergeladenen SQL-Dump vorgenommen) 
in diesem Falle ein index über das Feld loc_id mit dem Namen 
text_lid_idx. Damit wird eben die Tabelle nicht mehr vollständig, 
sondern nur noch sehr teilweise geladen.
Bei einer Suche nach einem Text wird der Index text_val_idx verwendet, 
bei Betrachtung nur bestimmter Typen text_type_idx und so weiter.
Lediglich ein kombinierter Index über text_val und text_type wäre 
vielleicht noch einer Überlegung wert.

Gruß

Peter Wendorff