On Monday, December 15, 2003 8:10 PM
Simon Fabian Becker <simon.fabian-Mmb7MZpHnFY@xxxxxxxxxxxxxxxx> wrote:
> Müsste man nur mal sehen, was die anderen dazu sagen ...
> Für die Hessen-Daten, die ich gerne zwischen den Jahren einpflegen
> würde, wäre es jedenfalls sinnvoll eine Änderung in irgendeiner Form
> vorzunehmen. Da müsste man sich jetzt entscheiden!
Es spricht doch nichts dagegen, die Gemeindeschlüssel in die bisher
dafür vorgesehene Spalte "gs" einzutragen. Dann gehen uns die schon mal
nicht mehr verloren. Wo ist also das Problem? - Oder habe ich in der
Eile was übersehen?
Unabhängig davon sollten wir aber schnell zu einer möglichst lange
tragfähigen DB-Struktur kommen, damit nicht laufend die GeoClass
angepasst werden muss und dann alle wochenlang (oder sind es etwa schon
Monate?) auf die neue Doku warten müssen...
Für die Administrative Gliederung scheint mir das Parent-ID-Modell das
einfachste (wie von Thomas Mack vorgeschlagenen). Die
Performance-Probleme, die beim rekursiven Auslesen entstehen, kann man
bei Bedarf auch nachträglich durch automatisch erzeugte, leseoptimierte
Hilfstabellen erschlagen (z.B. nach dem Nested Sets-Modell).
Die nicht eindeutig hierarchischen Daten (Kfz-Kennzeichen, PLZs)
brauchen entweder separate Tabellen oder wir müssen redundante Daten in
Kauf nehmen.
Hat einer von Euch Lust und Zeit, kurzfristig ein Wiki für das Thema
aufzusetzen? Das würde aus meiner Sicht die Sammlung der verschiedenen
Anforderungen und von konkreten Vorschlägen für die Datenbank erheblich
erleichtern (als Ergänzung zur Liste; nicht als Ersatz). Webspace kann
ich gerne stellen (inkl. Subdomain wiki.opengeodb.de).
Für den Fall, dass jemand in diesem Moment mit dem Gedanken spielt, mich
nach Webspace für ein Forum zu fragen: Meine Antwort lautet "Nein!"
Viele Grüße
Arne
--
http://klempert.de :: http://phpbar.de :: http://opengeodb.de
|
