Trigger als Lösung zu skriptgesteuerten Migration von Teststudenten
Die Migration von Teststudenten aus dem Entwicklungs- in das Qualitätssicherungssystem stellte bislang einen nicht unerheblichen Aufwand dar, da alle Schritte manuell vorgenommen werden mussten. Das Problem war hierbei, dass sich nicht ohne eigenhändiges Prüfen feststellen ließ, welche Testdaten nach der letzten Migration neu dazugekommen waren.
Um dieses Problem zu lösen und einen Automatismus entwickeln zu können, der die Migration der Testdaten weitgehend automatisiert, war es nötig, jeden neuen Datensatz in einer zweiten Relation abzulegen. Aus dieser können dann alle neuen Daten per Skript ausgelesen und in die Qualitätssicherung übernommen werden. Das Duplizieren der Datensätze sollte für die Clients transparent in der Datenbank erfolgen. Um dabei den Standard Namespace der Datenbank nicht mit eigenen Erweiterungen zu verschmutzen, wurde beschlossen, die Log-Relationen in einem eigenen Schema abzulegen. Das Kopieren der Daten erledigen Trigger.
Die eigentliche Funktionalität wurde dabei als dynamisch ladbares Modul in C implementiert. Dieses Modul unterscheidet zwischen Anlege-, Änderungs- und Löschaktion und erzeugt anhand der übergebenen Triggerdaten ein äquivalentes SQL-Statement für das Log-Schema.
Nachdem das Triggermodul nun erfolgreich arbeitet, steht als nächstes die Programmierung eines Migrationsskripts an. Dieses sollte in einer serialisierenden Transaktion sämtliche Daten aus den Logtabellen holen und diese leeren. Dadurch wird nicht nur eine einfachere Migrationsmöglichkeit geschaffen, sondern auch Konsistenz gewährleistet.