[Ontwerp] Hoe versiebeheer modelleren op content

[Goodielover]

In een poging het inhoudelijk niveau wat op te krikken en niet eeuwen te discussieren erover, het volgende discussie onderwerp (ook werkelijk probleem), normaal betrek alleen mijn collega's in zulke discussies, maar nu probeer ik dit ook maar eens:

Ik werk bij een bedrijf dat content beheert (niet per se web content). Deze content wordt up-to-date gehouden, maar soms is met nodig een of meerdere versies terug te kunnen (zeg de content van 1-1-1998), dus versiebeheer is noodzakelijk. Die content is onderling gerelateerd en ook die relatie kan veranderen.

Hoe zou je dit kunnen modelleren?

[Verwijderd]

Het makkelijkst is snapshots opslaan. Dus zodra je een wijziging wilt doorvoeren, de HUIDIGE toestand opslaan als versie [tijddatum], en daarna de wijzigingen doorvoeren. Je krijgt veel extra data, maar je kunt wel meteen terug naar een oudere versie.

Het cumulatief opslaan van wijzigingen is een andere methode, maar dit is erg complex, en wordt bijna onhandelbaar als je veel wijzigingen hebt op aan elkaar gerelateerde data: je kunt niet meteen terug naar een zekere versie, je moet eerst de cumulatieve wijzigingen terugdraaien, wat nogal wat tijd kan vergen.

[Goodielover]

Je oplossing kan alleen werken als er niet continu wordt gewerkt aan de content. Dat is hier wel het geval.
Een groep van meer dan 20 mensen doet niets anders dan content creëren en controleren. Ik kan dus geen afslagen maken van de DB op elk moment. Het moet zeg maar mogelijk zijn om op een willekeurig moment te kunnen bepalen: Wat was onze kennis van zaken op 21-7-1999.

Het moet dus gemodelleerd worden. Ik kan niet elke dag GB aan data backup-en, laat staan ontsluitbaar te maken.

[kvdveer]

Vervang alle queryies:

code:

UPDATE contenttable
SET content = 'bláát'
WHERE Id = '13992'

in

code:

SELECT @version := version + 1
FROM contenttable
WHERE Id = '13992';

INSERT INTO contenttable (Id,Version,Content,datum,...)
VALUES ('13992', @version, 'Blaet',UNIX_TIMESTAM(),...)

Je gooit een primary index op (Id,version).
Een transaction hieromheen is natuurlijk netter, maar dat is een implementatieprobleempje, geen modeleerprobleem.

[kvdveer]

Misschien wat vergezocht, maar CSV doet eigenlijk exact hetzelfde.

[thomaske]

Op maandag 04 maart 2002 10:42 schreef kvdveer het volgende:
Misschien wat vergezocht, maar CSV doet eigenlijk exact hetzelfde.

je bedoelt vast CVS

[edit]
meer info

[edit2]
ik weet niet of je er al eens van gehoord hebt, maar dit is precies wat je wilt. Iedereen kan aan de teksten sleutelen, alle versies worden opgeslagen, je kan altijd terug naar iedere versie, er wordt bijgehouden wat en wanneer iemand iets heeft aangepast, etc!

[chem]

er zijn mijn inziens 2 mogelijkheden:
opslaan volledige content (snel, foutloos)
opslaan verschil (weinig diskspace nodig, makkelijk te backuppen)

het opslaan van het verschil is niet eens zo heel moeilijk: als je per verschillende lijn het verschil opschrijft kom je al best ver (redelijk gelijk aan de filemerge binnen CVS)

[Goodielover]

De oplossing wordt maatwerk gebouwd hier in de hele workflow van de content afdeling.
Ik vraag hier niet om een technische oplossing, maar een ontwerp. ER-schema of object model.

Content heeft breakdown naar andere kleinere stukken content.
Content heeft geldig vanaf en geldig tot datum
Content heeft verwijzingsconstructie naar content (van een bepaalde versie)

chem: verschil opslaan is geen alternatief. Soms gaat het archief 30 jaar terug en dan de DIFF elke keer toepassen is teveel

[kvdveer]

Op maandag 04 maart 2002 10:52 schreef Goodielover het volgende:
chem: verschil opslaan is geen alternatief. Soms gaat het archief 30 jaar terug en dan de DIFF elke keer toepassen is teveel

Key-frames?
Eens in de 3 keer geen diff toepassen. Heb je een behoorlijke compressie gecombineerd met een goede snelheid.
Je kunt dit desnoods variabel maken.

[Verwijderd]

Op maandag 04 maart 2002 10:52 schreef Goodielover het volgende:
chem: verschil opslaan is geen alternatief. Soms gaat het archief 30 jaar terug en dan de DIFF elke keer toepassen is teveel

Waarom niet? Vind het een heel normale oplossing. Oracle9i kan momenteel al 8 petabyte aan, en dat is meer als genoeg om van 0 V. Chr totaan nu elke persoon op elk moment te registreren die zijn kont afveegt met een stuk toiletpapier dag in dag uit 24x7.

Rekenkracht wordt met het jaar dik verdubbeld, opslagruimte zelfde verhaal. Zie het probleem niet echt

[Verwijderd]

Op maandag 04 maart 2002 10:52 schreef Goodielover het volgende:
De oplossing wordt maatwerk gebouwd hier in de hele workflow van de content afdeling.
Ik vraag hier niet om een technische oplossing, maar een ontwerp. ER-schema of object model.

Er is geen 'special model' nodig. Wat je wilt is je database content terughalen van tijdstip Toud. Dus je wilt wat je op Tnu hebt opslaan zodat je het kunt terughalen op een tijdstip Ttoekomst. Dit houdt in dat je OF per wijziging de verschillen opslaat (wat source control systemen doen) OF je slaat per milestone je complete content op. Als er continu mensen content zitten te kloppen krijg je binnen een jaar een gigantische bak met data, ookal doe je niet aan version control. Iedere scheet opslaan is dan wat zonde. Maar, je kunt wel iedere versie die als 'published' of 'af' wordt bestempeld, opslaan. Wijzigingen daarop resulteren in een nieuwe versie, maar alleen indien daar weer 'published' of 'af' als kenmerk aan wordt gegeven. Zodoende sla je alleen de wijzigingen op die er iets toe doen. Het heeft geen zin om een serie wijzigingen aan d's en t's op te slaan in een zeker document tussen 2 versies in. (Niet voor archiveringsdoeleinden iig, het gaat immers om de inhoud)

Content heeft breakdown naar andere kleinere stukken content.
Content heeft geldig vanaf en geldig tot datum
Content heeft verwijzingsconstructie naar content (van een bepaalde versie)
chem: verschil opslaan is geen alternatief. Soms gaat het archief 30 jaar terug en dan de DIFF elke keer toepassen is teveel

Dat laatste geeft dus al aan dat je niets anders kunt doen dan versies compleet op te slaan. Dit moet je doen op het niveau van 'onderscheidbare units'. Dus niet bij het wijzigen van document A de complete database een nieuwe versie geven, maar op content-onderdeel niveau, bv de blokken waaruit documenten worden samengesteld, plus de samengestelde blokken (de documenten): immers heb ik document D wat opgebouwd is uit contentblokje C1 en C2 en ik wijzig C1 in C1', dan wijzigt D ook en dus een nieuwe versie.

[kvdveer]

ERD gaat me hier even niet lukken ivm graphics. (ascII art sux)
Dus bij deze het (afgeleide) databasemodel:

code:

Content (
  Id,         Het Id waarmee de content wordt opgevraagd.
  Version,     Het sequentieel versienummer van de content.
  TimeStamp,     Het timestamp van de huidige versie.
  [content]   De velden die de content beschrijven.
);

Dit systeem kun je toepassen op alle entiteiten... Het nadeel is dat dit snel erg groot wordt. (voor iedere typfout wordt de hele content gekopieerd)
Dit is op de lossen door met difs te gaan werken:

code:

Content-base (
  Id,         Het Id waarmee de content wordt opgevraagd.
  Version,     Het sequentieel versienummer van de content.
  TimeStamp,     Het timestamp van de huidige versie.
  [content]   De velden die de content beschrijven.
);

ContentDiff (
  Id,         Het Id waarmee de content wordt opgevraagd.
  Version,     Het sequentieel versienummer van de content.
  TimeStamp,     Het timestamp van de huidige versie.
  [content-diff]   Diffs van de velden die de content beschrijven.
);

Voor de laatste versie:
Neem de laatste Content-base waar datum < gewenste datum.
Neem alle Diffs met een versienummer > Content-base en datum < gewenste datum.
Voor alle diffs: pas diff toe op content.

Ik blijf hier trouwens uitgaan van een SQL-achtige database, maar het geheel is redelijk toepasbaar met een file-based database denk ik.

[kvdveer]

De uiteindelijke implementatie zal (voor zover ik het nu zie) dus afgaan hangen van de volgende punten:
• Hoe asyncroom werken medewerkers aan de content?
• Voldoen milestones, evt icm branches?
• Worden tijdelijke 'werkversies' opgeslagen?
• Hoe groot is het 'ruimte bezwaar' tov het 'performance bezwaar' voor het opslaan van historische versies?

[Goodielover]

Op maandag 04 maart 2002 12:21 schreef kvdveer het volgende:
De uiteindelijke implementatie zal (voor zover ik het nu zie) dus afgaan hangen van de volgende punten:
• Hoe asyncroom werken medewerkers aan de content?
Hoe moet ik in dit geval asynchroon interpreteren?
• Voldoen milestones, evt icm branches?
Elke dag is een milestone
• Worden tijdelijke 'werkversies' opgeslagen?
worden wel opgeslagen maar zijn geen versie
• Hoe groot is het 'ruimte bezwaar' tov het 'performance bezwaar' voor het opslaan van historische versies?
Performance is "the issue" tbv on-line ontsluiting

[Verwijderd]

Volgens mij is dit weer een typisch geval van "Eerst doen, dan nadenken".

Topicstarter: je kunt nu wel een antwoord willen, maar volgens mij ontbreekt het jezelf van essentiele informatie (en ons dus ook) en kennis om uberhaupt een antwoord te kunnen beoordelen.

Er zijn kennelijk eisen gesteld aan hetgeen moet worden opgeleverd, maar die heb je niet gegeven. De antwoorden die zijn gegeven zijn kennelijk niet goed genoeg, maar de reden daarvoor geef je niet. Je wilt een kant en klaar model, maar vergeet dat daar onderzoek aan vooraf gaat.

Version control is erg complex en vergt veel ruimte in je database en veel performance van je machine, al naar gelang je hoeveelheid content en je hoeveelheid versies.

Je kunt dit process versimpelen door alle data brute force op te slaan onder een "versie" en wanneer je terug wilt naar een zekere versie, pak je die dataset en doet DAAR je selecties op.

Wil je daarin gaan optimaliseren dan kom je onherroepelijk in aanraking met dingen als: willen we performance? of willen we een kleine footprint? Die dingen zijn afhankelijk van elkaar: veel performance is veelal de oorzaak van veel data, weinig data, is weinig performance. Weinig data en veel performance willen kan niet, immers hoe minder je opslaat, hoe minder data, maar minder opslaan bereik je alleen door verschillen op te slaan, compressie etc, zaken die performance vreten bij retrieval: een versie V is het resultaat van de oorspronkelijke versie met daarop uitgevoerd alle wijzigingen tot aan versie V, inclusief de wijziging die in versie V resulteerde.

Archiefbeheer, versioncontrol e.d. is een semantische bezigheid. Bij het ontbreken van grenzen aan de opslagcapaciteit is er geen vuiltje aan de lucht. Bij grenzen aan de opslagcapaciteit is het zaak semantische waarden te hechten aan wat je wilt archiveren en wat NUTTIG is te archiveren. Dat combineren met een bruteforce opslag van een complete versie lijkt mij imho de beste keuze, zeker wanneer je lange termijn opslag doet van veel wijzigende documenten.

(laat ik even in het midden of het uberhaupt nuttig is tig versies op te slaan van een document dat dagelijks wijzigt. Volgens mij wil je nl. gegevens met een zekere noemer opslaan onder een versie, niet documenten.)

[Goodielover]

Zoals ik in het begin ook al zei, is het voor mij een experiment met discussies over dit soort topics.
Met collega's zit je in dezelfde mind-set, je weet heel veel dingen, omdat het nu eenmaal zo is binnen je project.
Je kan in een discussie topic hier niet de hele projectgeschiedenis erbij halen. Het gebrek aan grafische mogelijkheden om even iets op het whiteboard te tekenen is ook hinderlijk.

Ik denk dat we vandaag wel tot een oplossing komen voor de storage van onze XML-content in een Oracle 8i DB.

[Verwijderd]

Op maandag 04 maart 2002 14:10 schreef Goodielover het volgende:
Zoals ik in het begin ook al zei, is het voor mij een experiment met discussies over dit soort topics.
Met collega's zit je in dezelfde mind-set, je weet heel veel dingen, omdat het nu eenmaal zo is binnen je project.
Je kan in een discussie topic hier niet de hele projectgeschiedenis erbij halen. Het gebrek aan grafische mogelijkheden om even iets op het whiteboard te tekenen is ook hinderlijk.

Ik denk dat we vandaag wel tot een oplossing komen voor de storage van onze XML-content in een Oracle 8i DB.

Zeker XML is uitstekend te archiveren. Evt. elke node separaat archiveren voor het veel data-veel perfomance verhaal wat Otis zojuist heel mooi heeft uitgelegd.

[Verwijderd]

XML files? En die heb je niet in een database staan? XML genereer je toch uit de data in de database, XML is niets anders dan een database in ascii (more or less). Ik zou nooit mn actuele content puur in XML files bewaren, maar ze met data uit een database genereren. Je focussed dan nl. op de content, waar het om gaat, en de structuur van die data is je tabellen-structuur incl. relaties.

[Scare360]

Voor versie beheer probleempjes hebben ze Visual Source Safe uitgevonden... ik gebruik het persoonlijk voor "alles". Van werkvloer documenten tot en met de echte sources van programma's. Plaatjes, memo's, intranet content, extranet content you name it.

[kvdveer]

Op maandag 04 maart 2002 19:34 schreef paulgielens het volgende:
Voor versie beheer probleempjes hebben ze Visual Source Safe uitgevonden... ik gebruik het persoonlijk voor "alles". Van werkvloer documenten tot en met de echte sources van programma's. Plaatjes, memo's, intranet content, extranet content you name it.

Het nadeel is dat VSS niet primair daarvoor bedoeld is: het werkt wel, alleen het werkt beter voor tekstgebaseerde code. Mijn eerder genoemnde CVS is ook een versiebeheersysteem, maar dan gratis.

[Verwijderd]

sterker: VSS voert geen versiebeheer uit op binaire files (kan ook niet, het is een textbased version control system).

[raptorix]

Daarnaast werkt VSS volgens mij niet met relaties, als je een file terug rolt dan kan je volgens mij niet zeggen dat de plaatjes waar het document aan gekoppelt is ook terug moeten rollen.

[kvdveer]

En natuurlijk is het 'tweak-gehalte' van zelf ontwerpen hoger!

[Goodielover]

Op dinsdag 05 maart 2002 10:57 schreef kvdveer het volgende:
En natuurlijk is het 'tweak-gehalte' van zelf ontwerpen hoger!

Precies. Het moet uitstekend aansluiten op de werkprocessen hier. En aangezien ik die hier niet allemaal kan uitleggen, zal ik de volgende keer proberen met een wat concreter ontwerp/programmeer probleem te komen.