Implementatie revisiebeheer

[T-MOB]

Ik zit met een systeem waarin er sprake is van een redelijk uitgebreide structuur. Er zijn objecten waarvoor de data afkomstig is uit 10+ databasetabellen. De data wordt door verschillende partijen beheerd en er is behoefte aan meer controle over wie wat kan. Dat houdt in dat men graag versies zou willen hebben, zodat er naar een oude staat kan worden teruggeschakeld. Maar ook dat er gewerkt kan worden in een versie welke dan na goedkeuring kan worden toegepast. Aan mij de taak om hier iets op te bedenken. Omdat dit
niet eenvoudig, maar toch ook niet ongewoon is wou ik hier graag eens pijlen of jullie goede ideeen hebben om dit te implementeren.

Wat had ik zelf zoal bedacht.

1. Gewenste wijzigingen opslaan in een takentabelletje. Afhankelijk van rechten kan de taak direct worden doorgevoerd of pas na goedkeuring. Voordeel is dat je op kenmerk-niveau wijzigingen kunt goedkeuren/afwijzen. Het nadeel is dat er best wat taken gedefinieerd en gebruikt moeten worden. Verder ben ik wat huiverig dat er conflicten kunnen ontstaan.

2. De objecten serializen of anderszins platslaan en dat in een versie-tabelletje gooien. Dit is makkelijker te realiseren. Maar het heeft wel wat nadelen. Je slaat een hoop redundante info op, er zijn wat technische hobbels als de onderliggende code wijzigt en dan heeft het in gebruik nog het nadeel dat het moeilijk is om verschillende versies te "mergen".

3. De structuur omgooien en zorgen dat OBJECT niet meer dan een schil wordt voor een verzameling OBJECTVERSIONS waarbij alles wat je op OBJECT aanroept dan "automagisch" wordt doorgezet op de actuele versie. Dit is een minder buggevoelige variant op 2. Het heeft nog steeds redundantie en het is nog steeds lastig om te mergen.

Het laatste is wat ik waarschijnlijk had gedaan als het syateem vanaf 0 gebouwd zou moeten worden. Dat is goed op een algemene manier te implementeren / in een code generator te bouwen. Nu neig ik meer naar optie 1 omdat die oplossing minder ingrijpend is. In principe kun je het ernaast optuigen en stapje voor stapje toepassen op de data.

Maar goed. Ik ben dus benieuwd of medetweakers wel eens een vergelijkbaar probleem hebben gehad. Zie ik een oplossingsrichting over het hoofd? Zijn er uitgesproken meningen voor of juist tegen een van de genoemde manieren?

[Hydra]

Hier valt weinig over te zeggen zonder dat je de datastructuur te kennen. In de basis wordt dit vaak gedaan door op de hoofdobjecten een versie veld aan te brengen en in plaats van updates altijd een insert te doen, en daarbij het versie veld op te hogen. Dit versieveld kun je ook koppelen naar een "versies" tabel waarin bijgehouden is van wie de wijziging is.

[T-MOB]

Qua structuur kun je (vereenvoudigd) denken aan een webpagina [hoofdtabel] die content heeft in een aantal talen [contenttabel - 1 rij per taal] en dan bijvoorbeeld ook een aantal foto's gekoppeld heeft [fototabel]. Het wijzigen van content in 1 taal of het toevoegen van een foto zou moeten leiden tot een nieuwe versie.
De implementatie zoals jij hem voorstelt (komt volgens mij neer op 3 uit mijn OP) leidt er dan toe dat je heel veel data moet dupliceren. Niet dat dit per se een probleem is, maar het doet vermoeden dat er een "betere weg" moet zijn.

[pedorus]

Het scheelt nogal welke bestaande frameworks er in gebruik zijn om dit aan te koppelen. Als je database bijvoorbeeld CouchDB is, dan heeft CouchDB versiebeheerfunctionaliteit sowieso al ingebakken, dus zou ik dat gebruiken