Am Mittwoch, 25. Oktober 2006 10:26 schrieb Stephan Schuster:
> >> Deshalb hatte ich mal gedanklich diese Datumsangaben aus der DB
> >> gestrichen. Aber gefallen tut es mir nicht wirklich.
> >
> >Mir ist der Zweck dieser Daten bis jetzt nicht ganz klar. Ich lasse
> > sie immer auf NULL ;-) Tut keinem weh und funktioniert trotzdem. Man
Fünfstellige Postleitzahlen gibt es erst seit dem 1.7.1993 in Deutschland,
also haben alle vierstelligen deutschen Postleitzahlen in valid_until =
30.6.1993, alle fünfstelligen Postleitzahlen ein valid_since = 1.7.1993 .
Das gleiche gilt für alle andere Einträge auch.
> > kann diese ruhig drin lassen. Ich würde sie aber nicht als
> > Voraussetzung bei einem Mindesteintrag definieren.
>
> Diese Daten dienen dazu, nachvollziehen zu können wie sich die Daten
> verändert haben. Solange Du immer den bestehenden Datensatz änderst ist
> das kein Problem, aber wenn Du mehrere Datensätze mit NULL hast, kannst
> Du nicht mehr entscheiden welcher der aktuelle ist!
>
> Wenn ich das DB-Schema richtig verstehe ist die "korrekte"
> Vorgehensweise folgende: Bei einer Änderung wird ein neuer Wert für
> valid_until gesetzt, der bestehende Datensatz kopiert, mit einem
> valid_from versehen und eben entsprechend den neuen Gegebenheiten
> geändert. Oder übersehe ich da etwas?
>
Nein, so ist das.
> Eine Löschung dieser Daten hätte auch Vorteile:
>
> - Die Abfragen würden einfacher (und damit wohl auch schneller) da
> einige Bedingungen entfallen
Naja, die Abfragen betrifft es am wenigsten, weil man nur ein "... and
valid_until >= date('today')" pro Tabelle mit reinschreiben braucht, um
aktuelle Daten zu bekommen.
> - Änderungen würden vereinfacht
>
> Um dennoch Änderungen am Datenbestand nachvollziehen zu können, könnten
> durchgeführte Änderungen in einer separaten Tabelle festgehalten
> werden. Dort würden bei der Änderung eines Datensatzes die alten Werte
> in einer "flachen" Struktur zusammen mit dem Datum der Änderung und
> einem Kommentar gespeichert. Anhand der loc_id wäre somit
> nachvollziehbar wie sich eine Location im Lauf der Zeit verändert hat.
>
Ich denke, man könnte Änderungen durch ein weiteres Attribut
identifizieren (boolean is_verified oder request oder so etwas).
Zusammen mit Datum der Anfrage und Hinweise auf den Eintragenden.
Das alles bräuchte auch nicht mehr in der Enduser-DB auftauchen,
könnte aber.
> Allerdings ist eine Änderung der DB-Struktur immer etwas heikel, da
> alle Nutzer ihre Datenbank und Ihre Applikationen umstellen müssen um
> die aktuellen Daten nutzen zu können. Das könnte wiederum die Akzeptanz
> der OpenGeoDB beeinträchtigen.
>
Ich denke, die Akzeptanz verbessert sich, wenn wir ein sinnvolleres
System haben.
> >>[...]
> >
> >Sind diese zeitlichen Informationen wirklich notwendig? Eigentlich
> > interessiert uns doch nur der aktuelle Status, also die zur Zeit
> > gültigen Werte. Oder übersehe ich etwas?
>
> Ja, die Datenbank ist für weitaus mehr geeignet als nur für
> PLZ-Umkreissuchen und das würde ich auch gerne so beibehalten, um den
> Nutzerkreis möglichst breit zu halten
>
Das finde ich zwar auch, aber in der Praxis wird die DB für Umkreissuchen
und Entfernungsberechnungen benutzt, und sonst so gut wie nicht. Selbst
das Wissen, daß man nicht nur Orte darin speichern kann, dürfte kaum
existieren ("Wozu sollen mehrere Einträge in geodb_hierarchies möglich
sein?").
Deshalb könnte man gut und gerne ein Ortsprojekt daraus machen, und es
würde praktisch niemand merken.
Ehrlich gesagt, bin ich mittlerweile dafür, es in diese Begrenzungen
zu konvertieren, um das Projekt mal in einen stabilen Zustand zu
überführen, der mit den Erwartungen übereinstimmt.
D.h., wir bringen es wieder in 0.1.3 Zustand zurück, denke ich.
Alles, was darüber hinaus existiert, kann in einem anderen Projekt
weiterexistieren, was aber nicht mehr öffentlich zu sein braucht.
> >[...]
> >Diese Gültigkeitsdaten machen die Sache zwar komplizierter aber nicht
> > unmöglich. Vor allem wenn man sie erstmal außen vor lässt (nicht aus
> > der DB schmeissen, sondern bei dem Admin-Tool erstmal nicht
> > berücksichtigen).
>
> Ich denke der Aufwand die Felder entsprechend zu füllen, sollte doch zu
> leisten sein, wenn ich das (so wie oben beschrieben) richtig verstanden
> habe. Ein Problem sehe ich vielleicht darin, dass die Felder wohl nicht
> den Zeitpunkt der Änderung in der Datenbank darstellen sollen, sondern
> den Zeitpunkt der administrativen Änderung (richtig?). Und das wäre
> etwas was der bearbeitende Administrator in Erfahrung bringen müsste.
>
Das kann ziemlich zeitaufwendig sein.
> >Ah, ok. Dann beschließen wir / beschließe ich jetzt, daß wir uns von
> > den Gültigkeitszeiträumen trennen. Und dann wird es simpel, denke
> > ich.
>
> Ich würde die bestehende Struktur mit Gültigkeit aus obigen Gründen
> gerne beibehalten, falls das Problem tatsächlich darin liegt, die
> tatsächlichen Daten für die Gültigkeiten zu ermitteln, könnte man dort
> ersatzweise zumindest das Datum der Änderung festhalten. Für Leute die
Ich denke, wir machen zwei Projekte. "Wir" heißt: ich mache ggf. mein
Projekt auf einer privaten Basis weiter, und die OpenGeoDB läuft als
reine Orts-DB mit aktuellen Daten weiter. Es müssen sich halt
Projektverantwortliche dafür finden, was aber leichter sein dürfte,
wenn die Schnittstellen einfacher sind, und das Projekt besser
überschaubar ist.
Thomas
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb-r1mDYR0DdAyzQB+pC5nmwQ@xxxxxxxxxxxxxxxx
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)
|
