[Alg] Database replicatie, hoe omgaan met deleted records?

[Verwijderd]

Ik ben bezig met een replicatie-systeem tussen 2 databases, en die moet platform/database onafhankelijk zijn. Dat heb ik nu allemaal prima voor elkaar, en op een aantal locaties is het ook al operationeel, maar ik heb nog 1 probleem waar ik nog geen goede oplossing voor heb:

Hoe weet de database waar naartoe wordt gerepliceerd welke records verwijderd zijn?

Tot nu toe heb ik 3 oplossingen kunnen verzinnen:

1) Laat de target database kijken in de source database welke records 'ie "teveel" heeft.
Dit is echter geen optie, omdat bij offline replicatie (uitwisseling via XML files) de target niet bij de source database kan. Bovendien is het te zwaar over bv. een dialup lijntje. Op een cruiseschip bij Tahiti hebben ze geen snelle ADSL-verbinding met de wal...

2) Voeg aan iedere tabel een 'Deleted' veld toe, en verwijder de records niet echt.
Te doen, maar dit betekent dat elke where clause van elke query hierop moet worden aangepast. En dat zijn er nogal wat.

3) Een 'on delete' trigger op iedere tabel die z'n primary key in een 'deleted records' tabel wegschrijft. Die records kunnen dan aan de andere kant door het replicatie-tool worden verwijderd.

Ik ben nu bezig geweest met de 3e optie, omdat daarvoor geen queries, etc. hoeven worden aangepast, maar het legt nogal wat beslag op de performance van de database (MSSQL in m'n tests, maar het moet ook draaien op InterBase en Oracle).

Iemand een geniaal idee?

[djluc]

2) Voeg aan iedere tabel een 'Deleted' veld toe, en verwijder de records niet echt.
Te doen, maar dit betekent dat elke where clause van elke query hierop moet worden aangepast. En dat zijn er nogal wat.

Een vaste DB layer gebruiken die je delete queries even omzet naar een update?

[Verwijderd]

Waarom is de on delete trigger zo'n performance probleem? Een recordje wegschrijven met iets van key, tabelnaam en datum/tijd zou toch niet zo'n probleem moeten zijn.

Ik heb ooit een (supersimpele) database replicatietool geschreven die gewoon gebruik maakte van de ON INSERT, ON UPDATE en ON DELETE triggers. Een tabel met 4 velden ACTIE (insert, delete, update), KEY,TABELNAAM en TIJD en hiermee was het mogelijk alles te repliceren.

Op het moment dat de replicatie daadwerkelijk plaats moet vinden kost het wel wat tijd om onnodige acties te verwijderen (5 updates op hetzelfde record zijn zinloos, 1 is genoeg) maar de triggers zijn zelf snel en simpel

[ Voor 61% gewijzigd door Verwijderd op 17-01-2005 16:30 ]

[Verwijderd]

Op zich is zo'n 'on delete' of 'before delete' trigger niet zo zwaar, maar bij cascaded deletes kan 't nogal in de papieren lopen...
Bovendien zijn vrijwel alle PK's samengestelde keys, die dan soms ook nog 's van integer of datum moeten worden omgezet in een string.
(Ik weet 't, misschien niet zo'n slim DB-ontwerp, maar als ik ga opperen om 400 klanten te updaten naar een nieuw ontwerp, krijg ik ruzie. )

@djluc, Het zijn juist de select-queries die aangepast moeten worden. En daar zijn er een boel van, zowel in de programma's zelf, in de gebruikte componenten en in bv. enkele honderden rapporten.

[Verwijderd]

In het geval van onhandige primary keys is methode 2 misschien beter. Maar dan moet je de cascaded deletes weer zelf gaan uitvoeren. Ook niet echt prettig.

Het aanpassen van de queries zelf is (hopelijk) niet een echt probleem. Overal AND DELETED=FALSE of WHERE DELETED=FALSE aan toevoegen is niet leuk maar meestal ook niet onoverkomelijk.

Ook kun je daar misschien omheen werken door gebruik te maken van views met de huidige naam van de tabellen en de tabellen te hernoemen.
De meeste databases ondersteunen wel updatable views als de views simpel genoeg zijn.
Views als

SQL:

SELECT * from table where deleted = false

zijn dat wel.
In dat geval hoef je dus de client code niet aan te passen maar blijf je met een ON DELETE trigger zitten die de cascaded deletes moet emuleren en misschien ook niet echt goed gaat presteren

[Verwijderd]

Verwijderd schreef op maandag 17 januari 2005 @ 16:16:
Ik heb ooit een (supersimpele) database replicatietool geschreven die gewoon gebruik maakte van de ON INSERT, ON UPDATE en ON DELETE triggers. Een tabel met 4 velden ACTIE (insert, delete, update), KEY,TABELNAAM en TIJD en hiermee was het mogelijk alles te repliceren.

Inserts en updates worden al prima afgehandeld: ieder record heeft een replication sequence veld, en deze wordt via triggers gewist bij een update. De replicatietool zelf zet er een nieuw sequence number in na replicatie, dus je hoeft alleen de records te repliceren die nog geen nummer hebben. Werkt op zich prima.

Nu het deleten nog...