[opengeodb] Konzept so noch ze itgemäß ?

[Andreas Müller]

Hallo zusammen,

das Problem was hier angesprochen wird ist meiner Ansicht nach folgendes:
Für die Erfassung und Aufbewahrung der Daten gibt es andere Anforderungen an
die Datenstruktur als für die Verwendung der Daten.

Diesen sachverhalt findet man fast immer wenn es um die Erarbeitung und
Nutzbarmachung von Daten geht. Ein kleines Beispiel für die Daten hier:
Klar ist es sinnvoll historische Daten im Erfassungssystem zu haben -
vielleicht braucht die ja jemand mal. Aber für eine aktuelle Umkreissuche,
Größenbewertung von Orten etc. brauche ich nur die Daten von heute - nicht
wie es vor 2 Jahre war. D.h. hier brauche ich nur die aktuellen Daten und
keine Historier die mir meine Datenbank nur aufbläht und verkompliziert.
Vielen hier reicht z.B. eine Tabelle sagen wir mit:
- Ort
- Ortsteil
- Land
- Bundesland
- PLZ
- Vorwahl
- Koordinaten

für den häufigsten Anwendungsfall einer Umkreissuche o.ä. Da dürfen dann
auch redundanzen drin sein weil wir reden hier von einer einzigen Tabelle
die man in sein System einbindet und gut ist.

Nun kommt erschwerend hinzu das viele Datennutzer nicht mit den
Erfassungsdaten umgehen können und daraus ihre Daten so extrahieren können
wie sie sie brauchen. Als Entwickler der Daten und Manager der
Erfassungsstruktur ist einem das oft nicht klar das andere da vor einem
unüberschauberen für sie nicht beherrschbaren Problem stehen. Wenn man sich
die Liste man ansieht kommen viele Fragen und Probleme genau aus dem
Bereich.

Ich würde daher Vorschlagen das man Anwendungsfälle definiert und für diese
Anwendungsfälle parallel zu den Rohdaten im Erfassungsformat spezilisierte
Datenbestände anbietet um die Anwendungsfälle damit zu bedienen. Diese
Formate sollten dann möglichst dauerhaft konstant bleiben das man hier
automatisierte Werkzeuge verwenden kann. Änderungen sollte man so gestalten
das für eine Übergangszeit altes und neues Format parallel verfügbar ist.

Über das Datenformat würde ich mir weniger Gedanken machen denn die
Datenbankwelt ist so bunt das man kein für alle passendes einheitliches
Format finden wird. Ich plädire bei soetwas immer für UTF-8 kodierte CSV
(aber richtiges CSV mit Escaping etc.) oder Tab-Limited-Text. In beiden
Fällen muss man sich noch über die Kodierung von Zeilenumbrüchen in Strings
einigen - ich verwende da hauptsächlich eine Textumschreibung wie "\r\n".
Auf keinen Fall würde ich XML nehmen da hier der Overhead und der
Verarbeitungsaufwand in keinem Verhältnis zum Nutzen steht - nicht für
solche Daten. Auch würde ich keine MySQL Dump nehmen - denn ein Oracle
Benutzer kann damit nichts anfangen. Diesem erst zu erklären er muss sich
irgendwo MySQL installieren, das dort einspielen und dann irgendwie von da
in sein Oracle bekommen führt eher dazu das der Benutzer die finger davon
lässt oder es genau einmal macht und danach mit veralteten Daten lebt.

Das ganze was ich hier schreibe sind langjährige Erfahrungen aus der Praxis
mit Daten im Automobil-Bereich. Wenn man das alles sauber aufbaut,
dokumentiert und kommuniziert gibt es keinen Ärger mehr.

Gruß,
Andreas

-- 
+--------------------------------------------------+
| Nur zwei Dinge sind unendlich:                   |
| Das Weltall und die menschliche Dummheit.        |
| Beim Weltall bin ich mir aber nicht ganz sicher. |
|                                                  |
| ~Albert Einstein~                                |
+--------------------------------------------------+