[opengeodb] nur deutschland

[Peter Wendorff]

Ich habe mir jetzt diese elende Diskussion durchgelesen, die hier 
zustande gekommen ist in den vier Tagen, die ich jetzt nicht da war.

Ein paar Anmerkungen dazu:

1) Primärschlüssel: Primärschlüssel sind für viele Tabellen da, für die 
anderen normalerweise nicht notwendig, weil die, in denen der 
Primärschlüssel fehlt, nur weitere Attribute zu den Entities in Tabellen 
mit Primärschlüsseln enthalten.
Insofern ist ein synthetischer Primärschlüssel normalerweise nicht 
notwendig - und wer ihn für die eigene Anwendung benötigt, der kann ihn 
sich notfalls doch erzeugen - in der Projektinternen Datenbank stimmen 
die Schlüssel, und zum Austausch mit der opengeodb als Ganzem werden 
diese zusätzlichen Schlüssel nicht benötigt.

2) Normalisierung: Die bestehende Datenstruktur ist optimiert für einige 
Aufgaben - zum Beispiel der Suche nach einem Text über eben verschiedene 
Typen hinweg. Ich kann nach Bremen suchen und kriege eben nicht nur die 
Stadt, sondern auch das Bundesland und diverse andere Daten dazu - ich 
muss dafür aber eben nicht unbedingt über alle Tabellen, in denen 
irgendwie ein Name als Text abgelegt ist suchen.
Insofern ist diese Zusammenlegung der Textdaten in einer Tabelle 
durchaus besser als die Trennung in einzelne Tabellen.

3) Das Trennen der Datenbank in einzelne Typ-Tabellen selbst ist aber 
nicht weiter kompliziert - da reicht je ein SQL-Befehl:
INSERT INTO detail_tabelle (Feld1, Feld2, ...) VALUES (SELECT * FROM 
opengeodb_text_data WHERE text_type=xxxx)

Wenn man jetzt detail_tabelle noch ein autoinc-Feld als Primärschlüssel 
gibt, hat man auch damit kein Problem, und über entsprechende DELETE- 
und ON DUPLICATE KEY- Constraints kann man das ganze auch für Updates 
anpassen, und über Einschränkungen zur Sprache oder zur nativen Sprache 
ist auch das rausschmeißen von Fremdsprachen kein Problem mehr.

Uwe Mengs schrieb:
> 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
Genau das kam mir auch als Gedanke - eine Download-Oberfläche, in der 
man die benötigten Attribute auswählt, die dann zu Exportdateien gepackt 
und zum Download bereitgestellt werden. Ob dies per Cronjob oder direkt 
und mit Caching-Mechanismen für häufig benötigte Daten bzw. 
Teildatenmengen erfolgt, ist eine andere Frage. Wer sich damit 
beschäftigen möchte, das zu implementieren - ich vermute, dass niemand 
etwas dagegen hätte.

Gruß
Peter Wendorff