Es ist wichtiger, etwas im Kleinen zu tun, als im Grossen darüber zu reden.
Willy Brandt
Relationale Datenbanken wie der SQL Server sind vielerorts im Einsatz. In älteren Anwendungen ist bei der Erweiterung nicht selten ein manuelles Ausrollen der Änderungen in Form von SQL-Skripts nötig. Bei Initiativen auf dem Weg zur Automatisierung besteht häufig ein Problem: es fehlen Skripte zum Aufsetzen für die Test- und Entwicklungsumgebungen.
Workarounds wie Backups einspielen haben Vor- und Nachteile. Wenn die Schmerzgrenze erreicht wird, werden häufig Ansätze für Migrationen mit dem Ziel der kontinuierlichen Integration in Angriff genommen. Initial wird ein Skript erstellt, das als Basis für das künftige Deployment dienen und die fehlenden Skripte kompensieren soll.
Default Constraints können auf dem SQL Server die Ausführung dieser Skripte blockieren, wenn diese bei der Erstellung einen zufälligen Namen haben, die pro Umgebung abweichen können. Dadurch schlagen Migrationen fehl, da bestehende Objekte mit einem anderen Namen wiederholt erstellt werden. Dieses Problem treffen wir sporadisch in Projekten an. Um auf dem SQL Server die Namen der Default Constraints zu vereinheitlichen, nutzen wir folgendes Skript:
DECLARE @sql varchar(MAX) = '' SELECT @sql += 'EXEC sp_rename @objname = ''' + SCHEMA_NAME(dc.schema_id) + '.' + dc.name + ''', @newname = ''DF_' + SCHEMA_NAME(dc.schema_id) + '_' + OBJECT_NAME(dc.parent_object_id) + '_' + c.name + ''', @objtype = ''OBJECT''; ' FROM sys.default_constraints dc JOIN sys.columns c ON c.object_id = dc.parent_object_id AND c.column_id = dc.parent_column_id WHERE dc.name != 'DF_' + SCHEMA_NAME(dc.schema_id) + '_' + OBJECT_NAME(dc.parent_object_id) + '_' + c.name AND OBJECT_NAME(dc.parent_object_id) != 'dtproperties' EXEC(@sql)
Dies führen wir in der Regel auf einer bestehenden Datenbank aus, bevor wir das Initialskript erstellen. So können die Skripte für die Automatisierung auf der bestehenden Datenbank und als Grundlage für neue Umgebungen wie Test- und BDD-Umgebung genutzt werden.