Mutatie database ontwerp, tips?

[DrDelete]

Door een applicatie wordt in een transactie een paar lokale tabellen geupdate't. Aan het einde van transactie wordt ook een kleine subset van die data in een aparte mutatietabel gezet. Die mutatietabel wordt door een Windows Service eens in de zoveel tijd ingelezen waarna elk mutatie naar een webservice wordt gezonden. Het eindpunt van de webservice pikt de mutatie op en update zijn eigen database weer, deze database is qua omvang en structuur anders.

Waar moet rekening mee worden gehouden qua vormgeving van de mutatietabel zodat de mutaties uiteindelijk een consistent eindbeeld geven van de database?

Bijvoorbeeld: er moet een datum/tijd stempel per mutatie zijn om te bepalen wat in welke volgorde moet worden aangeboden aan de webservice, maar moet deze datum/tijd zijn van het startmoment of het eindmoment van de transactie zijn?

[Pete]

Ik denk dat deze vraag niet simpel te beantwoorden is. Dit hangt namelijk volledig af van het type database, het type queries, de hoeveelheid mutaties en hoe kritisch de database is.

Je vraag nu is of je het begin of eindpunt van transacties moet opslaan. Kunnen (en mogen) deze transacties door elkaar heen lopen dan? En als deze transacties door elkaar heen lopen, heeft dat invloed op de resultaten? Oftewel wat is de isolation mode van je lokale database?

En hoe wil je de mutaties exact opslaan. Als queries of als...

Ik denk dat je eerst een goede schets moet geven van je database voordat iemand je echt kan helpen hiermee.

[FragFrog]

Is het niet simpeler om de databases dat zelf te laten doen? MSSQL bijvoorbeeld kan prima met enige regelmaat transacties bijwerken.

[Acid__Burn]

FragFrog schreef op maandag 10 september 2007 @ 14:25:
Is het niet simpeler om de databases dat zelf te laten doen? MSSQL bijvoorbeeld kan prima met enige regelmaat transacties bijwerken.

Je bedoeld transactionlog-shipping?

[Edit]:
Ehm... Log-shipping bedoel ik dan...

[ Voor 8% gewijzigd door Acid__Burn op 10-09-2007 14:27 ]

[reddevil]

Wij doen het altijd middels een eigen event tabel. Als er een mutatie ergens plaatsgevonden heeft, maak je een nieuw record in de mutatietabel met een status van bijv. 'nieuw'.

Een andere applicatie die kan dan de mutaties ophalen op volgorde van datum (kan in vele gevallen ook gewoon gesorteerd op een autoincrement veld). Tijdens het behandelen van een event wordt de status ervan op 'in bewerking' gezet.

Na afhandeling wordt de status op iets van 'done' gezet.

Wat betreft de datum lijkt mij de timestamp aan het eind van de transactie (ik neem aan dat je de tabellen achter elkaar update via een stored procedure ofzo?). Ik ga er vanuit dat je pas aan het eind een commit doet en niet tussen elke update door

[leuk_he]

FragFrog schreef op maandag 10 september 2007 @ 14:25:
Is het niet simpeler om de databases dat zelf te laten doen? MSSQL bijvoorbeeld kan prima met enige regelmaat transacties bijwerken.

Ik ken MSSQL niet goed, maar werkt dat ook als de destination database een andere stuktuur heeft?

De exacte manier van werken hangt erg samen met de requirements, en met name de performance Voor miljoenen records synchen moet je nou eenmaal heel anders werken als 100 records syncen, en voor een multiuser systeem waar het risico groot is dat gebruikers dezelfde records raken zul je locking/timestamping anders moeten aanpakken dan een systeem dat in essentie single user is.

Wel lijkt me dat je timestamps op het bronsysteem zult moeten aanmaken, dat is het invooer systeem, en dat is de waarheid van de data?

[ Voor 42% gewijzigd door leuk_he op 10-09-2007 14:45 ]

[DrDelete]

Het is een webapplicatie en dus multi user. Ik wil per gebruiker een transactie opbouwen en binnen die transactie wil ik als eindresultaat dat de mutatierecords opeenvolgend in de database komen.

Na analyse blijkt dat auto increment absoluut niet geschikt is voor chronologisch verwerken van de mutatierecords. Bij multi user inserts in combi met auto increment fields, komen de records van verschillende gebruikers kris kras door elkaar te staan. Door achteraf te sorteren op auto increment field en dan sequentieel de mutatietabel door te lezen is dus dan geen optie.

De oplossing die ik nu voor ogen heb is om 2 tabellen te maken. 1 tabel die deze structuur heeft:

TransactieTabel

TransactionID	GUID
TransactionStartTime	DateTime
TransactionEndTime	DateTime

MutatieTabel

TransactionID	GUID
MutatieCode	Int
MutatieVolgnummer	Int
etc	etc

Zou dit nog concurrency problemen kunnen opleveren die ik nog niet heb voorzien?

[NMe]

Waar hoort mijn topic?

PRG>>SEA

[SPee]

Ik wil per gebruiker een transactie opbouwen en binnen die transactie wil ik als eindresultaat dat de mutatierecords opeenvolgend in de database komen.

Dus de eerste deel van de transactie moet bovenaan, de 2e eronder, etc?
Dat lig er dan helemaal aan hoe jij die mutaties wegschrijft. Zolang je het in de juiste volgorde doet, komen ze op die manier binnen.

Of bedoel je dat rij 1 tot 5 bij dezelfde user met dezelfde transactie horen?
Dit is dan alleen te realiseren door maar 1 thread naar de database te laten schrijven. In een webapplicatie niet te doen, vanwege de vertragingen die gaan oplopen.

Als je het echt chronologisch wilt zou ik een extra kolom maken met een volgnummer voor in de transactie en die dan later in een 'order by' gebruiken.
Het is namelijk praktisch onmogelijk om in een multi-user omgeving te garanderen dat records voor een enkele user achter elkaar in de database komen. Wat als je handmatig een entry in de database maakt