[Alg] Track changes implementeren

[xos]

Ik ben bezig met een systeem waarin met dossier wordt gewerkt. Deze dossiers bestaan uit een aantal velden welke in de loop van de tijd kunnen aangepast worden.

Het probleem is dat de klant de eis stelt dat rapportages uit het verleden weer opnieuw uitgeprint kunnen worden. Dus wanneer een oude rapportage opnieuw wordt uitgeprint dienen veranderingen na de oorspronkelijke datum van de rapportage niet meegenomen te worden. Er moet dus worden bijgehouden welke veranderingen zo'n dossier meemaakt.

Ik heb zelf een paar opties bedacht.

• Een trigger aan een update query in de database te hangen. Op die manier kan automatisch het oorspronkelijke dossier worden gekopieerd en het huidige dossier worden aangepast.
• Via de code kan een nieuwe dossier worden aangemaakt.
• Alle gegenereerde rapportages opslaan & indexeren en weer heropvraagbaar maken.

Maar bovenstaande oplossingen hebben 1 groot nadeel. Deze oplossingen kosten erg veel ruimte.

Verder hebben de eerste 2 punten het nadeel dat bijgehouden moet worden welke query er is losgelaten op de database om hetzelfde rapport weer te kunnen genereren.

Een andere moglijkheid is bij te houden welke velden nu precies zijn veranderd. Maar dit lijkt mij best complex worden. Volgens mij moeten er dan kolomnamen uit de dossiertabel in een kolom worden opgeslagen. Iets wat mij niet echt lekker in de oren klinkt. Verder worden in de toekomst zeer waarschijnlijke nieuwe type dossiers toegevoegd aan het programma met andere velden. Er zou dus een algemene oplossing voor moeten komen.

Ik ben benieuwd of andere leden ideeen hebben over dit probleem en/of mij een richting kunnen geven voor een oplossing

[djc]

Je zou ook een bepaalde representatie van het huidige dossier kunnen opslaan ergens zodra het dossier gewijzigd wordt (juist daarvoor, of juist daarna).

Ruimte kost het toch wel -- je wil een grote hoeveelheid data bewaren.

[NMe]

Ontwerp mag bij onze nieuwe buren in Software Engineering & Architecture.

PRG>>SEA

[xos]

Manuzhai schreef op dinsdag 21 maart 2006 @ 13:20:
Je zou ook een bepaalde representatie van het huidige dossier kunnen opslaan ergens zodra het dossier gewijzigd wordt (juist daarvoor, of juist daarna).

Ruimte kost het toch wel -- je wil een grote hoeveelheid data bewaren.

Dat is idd een mogelijkheid welke ik nog niet bedacht had. Het heeft wel de consequentie dat oude dossiers niet meer via een gangbare query op te vragen zijn. Maar gelukkig gaat het alleen om oude rapportages welke hopelijk niet te vaak opgevraagd hoeven worden.

[Metalman]

Ik zou persoonlijk gaan voor de opslag van meerdere versies van hetzelfde dossier (een beetje zoals MediaWiki dit doet). Als er iets gewijzigd wordt krijgt een document een hoger versienummer en de huidige datum/tijd mee, en wordt die apart opgeslagen. Volgens mij is dat de handigste manier om ook oude versies nog te kunnen bekijken/printen. Dat het wat meer opslagruimte kost lijkt me nogal wiedes, maar daar ontkom je hiermee toch niet echt aan ben ik bang.

Bovendien kost opslag relatief weinig, dus een grotere harddisk in je server (of je RAID array uitbreiden) is geen probleem lijkt me. Uiteraard hangt dit wel af van hoeveel dossiers er gaan komen, hebben we het over honderden, duizenden, miljoenen? In de eerste twee gevallen zou ik me niet al te druk maken om opslagruimte. Met pak 'em beet 2 tot 5 duizend dossiers kom je (afhankelijk van de hoeveelheid tekst) misschien op een paar honderd MB uit qua database grootte.

Misschien praat ik wel onzin hoor, maar ik redeneer nu puur uit eigen ervaring en boerenverstand. Ik weet niet wat jouw systeem moet doen, hoeveel gegevens erin komen, etcetera dus het is lastig te beoordelen of dit een goede oplossing kan zijn.

[Infinitive]

Ik zou zelf voor een trigger op de tabel gaan. Maak een history tabel aan (zelfde structuur als de oorspronkelijke tabel, maar met een extra veld, zoals de wijzigingsdatum) en een trigger op de oorspronkelijke tabel die na elke wijziging een volledige kopie maakt. Dat gebeurt dan automatisch en heb je er verder geen omkijken meer na. Verder kan je de history-tabel raadplegen mocht je een oude versie willen ophalen. Omdat de structuur veel op de oorspronkelijke structuur lijkt, zou het bijhouden van een dergelijke geschiedenis je niet veel extra werk moeten kosten.

Deze oplossing is wel het minst zuinig wat betreft opslagruimte. Maar je history-tabel zal je als goed is bijna niet raadplegen, dus daar zou je kunnen kiezen voor compressie en eventueel het verplaatsen van records ouder dan een bepaalde leeftijd naar een ander medium (naar tape ofzo).

[xos]

offtopic:
Sorrie voor de late reactie, ik kreeg meer time-outs dan pagina's voorgeschoteld gisteren.

@Metalman
Momenteel gaat het over duizenden, de verwachting cq de hoop is dat dat aantal flink stijgt. Het aantal gegevens van een dossier wisselt erg sterk. Ik weet niet wat voor dossier types er in de toekomst nog worden aangevraagd maar waarschijnlijk zullen deze +/- 75 velden bevatten. Ik heb de klant verteld dat deze eis komt met een stuk grotere dataopslag. Maar schijftuimte kost ook niet zoveel dat het een echt groot probleem is. Bijkomend voordeel is dat een overzicht van aanpassingen makkelijk tevoorschijn getoverd kan worden wanneer hier in de toekomst om gevraagd wordt.

@Infinitive
Mijn persoonlijke keuze zou ook richting een trigger gaan omdat het lekker eenvoudig is. Het beetje extra informatie wat bijgehouden moet worden ben ik niet zo bang voor. Het probleem doet zich voor bij het kopieren van gehele dossiers. Maargoed, uit jullie posts merk ik op dat het probleem met extra opslag in dit geval maar op de koop toe te nemen is.

Iig bedankt voor jullie input

[Mithrandir]

Een paar duizend records dat er misschien enkele tienduizenden worden is peanuts voor welke database dan ook.

Je moet geen kunstgrepen uithalen maar gewoon alles in een history-tabel gooien. Zelfs al zou de hardware een probleem worden, een nieuwe databaseserver is goedkoper aan te schaffen dan het kost om jou een ingewikkeld systeem te laten maken.

Die paar gigabyte van de data kost ook niet een 'stuk grotere dataopslag'; het was betrekkelijk klein en blijft ook betrekkelijk klein. Qua tijdcomplexiteit: honderdduizenden records lijkt veel maar met een paar goede indexes gaat het zoeken supersnel. Een database is ervoor gebouwd om met veel records om te gaan.

xos
[...]
Maargoed, uit jullie posts merk ik op dat het probleem met extra opslag in dit geval maar op de koop toe te nemen is.
[...]

Die extra opslag ís geen probleem. Een database gaat niet op z'n gat met honderdduizenden records, met miljoenen wordt het misschien een ander verhaal, maar daar ben je nog lang niet. En zelfs dan is het op te lossen door een paar goede indexes en misschien een nieuwe server.