[opengeodb] OpenGeoDB unterstützen

[Oliver Hohl]

Hi,
>> Man kann auch die selbe Struktur zweimal anlegen, eine als aktuell
>> gueltiger Bestand, und eine
>> zweite Version, die die Aenderungen ueber der Zeit als Log mitfuehrt.
> Hier würde ich einwenden, dass redundante Strukturen mehr Aufwand bedeuten
> und nicht unbedingt wünschenswert sind.
Viel mehr Aufwand kann ich hier nicht wirklich erkennen. Eintraege in solche
Log-Tabellen kann man mit nahezu null Aufwand uebertragen, und das 
haette den
Vorteil, dass die eigentlichen Tabellen, die ja fuer die normalen Abfragen
relevant sind, nicht mit Archiveintraegen zumuellt. Das wuerde dann eher
wieder etwas in Richtung Laufoptimierung bringen.
>> Das macht ja auch durchaus Sinn. Man koennte sich ja evtl. ueberlegen,
>> ein paar Views zu
>> definieren, die fuer unterschiedliche Anwendungen gestrickt sind und
>> dadurch die Abfragen
>> schon mal etwas erleichtern.
> Ich denke die meisten Nutzer verwenden MySQL als DB-Engine, was die
> Verwendung von Views leider erst ab Version 5.0.1 unterstützt. Und nur
> wenige werden einen eigenen Server administrieren, was ein Update oft
> unmöglich macht.
Man kann die Views ja trotzdem mit als "Erweiterung" fuer die Leute 
dazupacken, die andere
DBMS einsetzen. Ich faende es nur schade, auf so maechtige Tools zu 
verzichten, wenn sie
einem doch etwas Arbeit abnehmen koennen.
>
>>>
>>>> [...]
>>> 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.
>>>
>> Was spricht denn dagegen, sowohl den Zeitpunkt der "administrativen"
>> Aenderung, als auch die
>> Zeitpunkte der Datenbank-Aenderungen mitzuprotokollieren? Es gibt sicher
>> fuer beide Faelle
>> Anwendungsgebiete. Und wirklich mehr Stoff kostet das auch nicht.
>
> Da stimme ich Dir zu, soweit eben der Zeitpunkt der administrativen
> Änderung bekannt ist. Und für den zeitpunkt der Datenbank-Änderung ließe
> sich auch eine zusätzliche Tabelle mit loc_id als Fremdschlüssel, dem 
> Datum
> und einem Kommentar-Feld (ähnlich die jetzige changelog-Tabelle)verwenden.
> So können auch reine Korrekturen protokolliert werden (die keine Änderung
> bei valid_since und valid_until erzeugen) und die Struktur kann 
> beibehalten
> werden.
oh, da ist wohl bei der graphischen Struktur der DB die Changelog-Tabelle
vergessen worden...
Aber mit solch einer Tabelle hast Du ja auch keine Moeglichkeit, Daten
wiederherzustellen, wenn die mal eingetragen wurden. Und mit einer 
Duplizierung
haette man den revert-Mechanismus eigentlich schon fast drin.
>> Wenn man abschaetzen kann, was man tun muss, ist eine Zusage leichter zu
>> geben ;-)
> Was genau zu tun ist muss eben noch abgesprochen werden, aber es wäre gut
> zu wissen, auf wieviele Leute sich die Aufgaben verteilen lassen
hehe, irgendwie drehen wir uns so im Kreis ;-)

    Olli