2010-08-04 7 views
5

Ich benutze eine MS SQL Server-Datenbank und verwenden viele Ansichten (für die Verwendung mit einem O/R-Mapper). Ein kleines Ärgernis ist, dass ich möchteWie behandelt man db-Schema-Updates, wenn Schemabinding und Updates oft

  • Verwendung Schemabindung
  • Update mit Skripten (zu auf Servern bereitstellen und in einem Quellcodeverwaltungssystem setzen)

aber laufen in das Problem, das wann immer ich will z Wenn Sie einer Tabelle eine Spalte hinzufügen, muss ich zuerst alle Ansichten löschen, die auf diese Tabelle verweisen, die Tabelle aktualisieren und dann die Ansichten neu erstellen, auch wenn die Ansichten andernfalls nicht aktualisiert werden müssten. Dies macht meine Update-Skripte viel länger und auch, wenn man die Diffs im Quellcode-Kontrollsystem betrachtet, ist es schwieriger zu sehen, was die tatsächliche relevante Änderung war.

Gibt es einen besseren Weg, damit umzugehen?

Ich muss immer noch in der Lage sein, einfache und Source-steuerbare SQL-Updates zu verwenden. Ein Code-Generator wie in SQL Server Management Studio enthalten wäre hilfreich, aber ich hatte Probleme mit SQL Server Management Studio, da es dazu neigt, Code zu erstellen, der die Namen für einige Indizes oder (Standard) Einschränkungen nicht angibt. Aber ich möchte identische dbs haben, wenn ich meine Skripte auf verschiedenen Systemen laufe, einschließlich der Namen aller Einschränkungen usw., damit ich beim späteren Aktualisieren dieser Einschränkungen nicht durch Schleifen springen muss.

Also wäre vielleicht ein schlauer SQL-Code-Generator eine Lösung?

Mein Workflow ist jetzt: "cannot ALTER 'XXX' because it is being referenced by object 'YYY'"

  • Typ der alter table Anweisung in Abfrage-Editor
  • überprüfen, ob ich eine Fehler Aussage wie erhalten
  • Verwendung SQL Server Managment Studio Skript ich create Code für das referenzierte Objekt
  • eine drop Anweisung vor der ALTER-Anweisung einfügen und Anweisung erstellen, nachdem
  • prüft, ob die drop Anweisung Fehler erzeugt und wiederholt

das ärgert mich, aber vielleicht muss ich einfach damit leben, wenn ich weiterhin Schemabinding und Skriptaktualisierungen verwenden möchte ...

Antwort

2

Sie können das "check if I g et ein Fehler "Schritt, indem Sie einige dynamische Managementfunktionen und Systemansichten abfragen, um Ihre Abhängigkeiten zu finden. This article gibt eine anständige Erklärung, wie man das macht. Darüber hinaus denke ich, dass du Recht hast, du kannst deinen Kuchen nicht essen und ihn auch nicht mit Schemabindungen essen.

Bedenken Sie auch, dass das Löschen/Erstellen von Ansichten dazu führt, dass Sie alle Berechtigungen verlieren, die für diese Objekte erteilt wurden. Diese Berechtigungen sollten daher ebenfalls in Ihren Skripts enthalten sein.

+1

Oh, gut. Ich denke, ich werde damit leben. Idealerweise möchte ich: a) keine Fehlermeldung, wenn das Tabellenupdate die Ansichten nicht wirklich beeinflusst (z. B. das Hinzufügen einer neuen Spalte sollte die schreibgeschützten Ansichten dieser Tabelle nicht beeinflussen) b) Fehlermeldung, wenn die Tabelle Aktualisierungen aktualisiert (zB Löschen einer Spalte, die in einer Ansicht verwendet wird) Aber ich denke MSSQL funktioniert einfach nicht so (möglicherweise aus guten Gründen ...) Danke für die Erlaubnisserinnerung! –

Verwandte Themen