Solche und ähnliche Fragen sind häufig zu beobachten. Die Antwort ist allerdings nicht immer einfach, da es sich hier eigentlich um Zeilenpositionierungsprobleme handelt, die streng genommen einer relationalen Datenbank mit ihrem set-basierten Ansatz widersprechen. Trotzdem gibt es auch hier diverse Lösungen...
Original von Tibor Karaszi; deutsche Übersetzung von Frank Kalis
Überblick
Die Verwendung Gespeicherter Prozeduren wird allgemein als gute Praktik betrachtet. Einer der Vorteile Gespeicherter Prozeduren ist deren Vorkompilierung. Dies bedeutet, dass zur Ausführungszeit SQL Server den vorkompilierten Ausführungsplan der Gespeicherten Prozedur aus dem Cache holt und ausführt, falls dieser bereits im Cache vorhanden ist. Dies ist generell schneller als den Code bei jeder Ausführung zu optimieren und kompilieren. Unter bestimmten Umständen jedoch, ist es jedoch notwendig, eine Prozedur während der Ausführung neu zu kompilieren.
Original von Tibor Karaszi; deutsche Übersetzung von Frank Kalis
Übersicht
Im folgenden finden Sie verschiedene Techniken und Produkte, die DDL Skripte für Ihre Datenbankobjekte und/oder INSERT Statements für Ihre Daten generieren können.
Zusatzinformation
Ich empfehle, dass Sie DDL wie Quellcode behandeln. Typischerweise bedeutet dies, dass Sie Ihr DDL in Dateiform aufbewahren und generell ein Quellcodeverwaltungsprogramm verwenden, dass Sie Objekte ein- und auschecken lässt und auch in der Lage ist, verschiedene Versionsstände Ihres Datenbankschemas zu verwalten.
Original von Narayana Vyas Kondreddi; deutsche Übersetzung von Frank Kalis
Traditionell waren SQL Server Datenbankentwickler es gewohnt, SELECT zu verwenden um Werte einer Variablen zuzuweisen. Dies funktionierte einwandfrei und war eine absolut gültige Praktik in SQL Server 6.5. Microsoft veröffentlichte SQL Server 7.0 in 1999. Diese Version führte das SET Statement ein, um Variablen zu initialisieren und Werte zuzuweisen. In der onlinedokumentation konnte man ebenfalls nachlesen: "Es ist empfohlen, dass SET @local_variable anstelle SELECT @local_variable verwendet wird zur Variablenzuweisung."
Dies hängt eigentlich von der Applikation ab, mit der sich die Benutzer zum SQL Server verbinden. Tatsache ist, dass sysdatabases von jedem Benutzer gelesen werden kann, der sich verbindet. Egal, ob die Applikation nun die Datenbanken zeigt oder nicht, wenn die Benutzer
Vielfach ist es üblich, dynamisches SQL zu verwenden, wenn eine Prozedur für verschiedene Sortierkriterien verwendet werden soll. Dabei kann dieses dynamische SQL relativ einfach vermieden werden.
Nicht wirklich. Da bei einem INNER JOIN nur die Werte beider Tabellen gefunden werden, bei denen die Spaltenwerte die per JOIN verknüpft werden, identisch sind, gilt folgendes:
A=B
was logischerweise auch bedeutet:
B=A
Von daher ist die Tabellenanordnung irrelevant. Intern wird der Query Optimizer von sich aus eine Entscheidung treffen, in welcher Reihenfolge auf die Tabellen am effektivsten zugegriffen werden kann.
Nun, erst einmal gibt es keine *IDENTITY* Spalte. IDENTITY ist eine Eigenschaft, die für numerische Spalten definiert werden kann.