Umzug einer Datenbank von einer Location in eine Andere, von einem Server zu einem Anderen oder überhaupt: Das HowTo von Microsoft, für ältere Versionen auch noch DTS-Packages dafür.

Wie speichert man hierarchische Daten (Bäume, Graphen…) effizient in einer relationalen Datenbank. Die Grundgedanken dazu müssen ersteinmal bestimmen, in welche Richtung hauptsächlich optimiert werden soll:

• schnelles Lesen der Baumstruktur
• schnelles Einfügen Elementen
• schnelles Ändern von Zuordnungen

Um alle Optimierungen gleichzeitig effizient zu bekommen, ist mir nichts Passendes untergekommen. Wohl läßt sich mit Stored Procedures und einigen Kniffen einiges erreichen, denoch bleiben bei jeder Implementierung Wünsche offen:

Tree

• Ravi S.Maniam: MS SQL Server 2008 und neuer Datentyp HierarchyID
• James Crowly: Tree Structures in .NET und MS SQL

DAG (Directed Acyclic Graph):

• Joe Celko Einführung, Nested Sets
• Kemal Erdogan (MS SQL) auf CodeProject.com
• Storing Hierarchical Data in a Database

Nested Sets

• Nested Sets in Wikipedia
• sehr gut: Arne Klempert über Nested Sets
• Workshop Nested Sets (PHP, MySQL)
• Benchmarks DBTree
• Dan Radu: alles in einer Tabelle: Tree utilities in SQL Server 2000 and 2005, and OLAP implementation

Diese kleine Sammlung stammt noch aus Mitte 2008, hatte sich im Entwurfsordner versteckt…

Warum hat MS SQL die wirklich hilfreiche Funktion REPLACE aus MySQL nicht? Gut, ab Version 2008 gibt es etwas vergleichbares namens MERGE. Aber in Vorgängerversionen muss man sich mit einem Workaraound behelfen. Keith hat bei stackoverflow.com eine Funktion Namens “upsert” (von UPdate und inSERT) veröffentlicht.

siehe upsert bei stackoverflow.com

In Microsofts SQL-Server soll weiterer dynamischer Code zu jeder Zeile einer Abfrage ausgeführt werden. Bei Oracle gibt es dafür FOR EACH row. MS T-SQL hat dieses Konstrukt noch nicht, hier muss man sich mit einem Workaround behelfen. Justin Carmony hat sich damit intensiv beschäftigt. In den Kommentaren sind noch verschiedene andere Möglichkeiten aufgeführt.

Es fehlt aber noch eine recht einfache über die ab Version 2005 verfügbaren Common Table Expressions:

DECLARE @cnt int
DECLARE @cntMax int
SELECT @cnt=1;
SELECT @cntMax =Count(ID) FROM myTable WHERE x=1 

DECLARE @y int
WHILE @cnt <= @cntMax
BEGIN --While Loop
	WITH AbfrageLoop AS (
	SELECT row_number() OVER (ORDER BY ID) AS Row,*
		FROM  myTable
		WHERE x=1
		)
	SELECT @y=y FROM AbfrageLoop WHERE Row=@cnt

	--do something based on the query
	DELETE FROM AnotherTable WHERE AnotherY=@y

	SELECT @cnt = @cnt+1
END --While Loop

siehe Justin Carmony, MS MSDN

Möchte man im MS SQL-Server Code zur Laufzeit generieren und Ausführen lassen (hier im Trigger), ist das kein großes Problem:

DECLARE @SQL nvarchar(200)
SET @SQL=N'SELECT xy FROM myTable WHERE x=1'
EXEC @SQL

Schwieriger wird es, wenn die Abfrage eine Prüfung durchführen soll und aufgrund des Ergebnisses weitere Aktionen ausgeführt werden. Das bedeutet, dass ein Ergebnis zurück in den aufrufenden Code transferiert werden muss. Leider läuft jede EXEC-Anweisung in einem eigenen Kontext, auf den von außen nicht zugegriffen werden kann. Dieses Problem muss man umgehen.

DECLARE @SQL nvarchar(200)
DECLARE @rueckgabe int
SET @SQL=N'SELECT xy,@min=min(y) FROM myTable WHERE x=1'
EXEC sp_executesql @SQL, N'@min int OUTPUT', @rueckgabe OUTPUT
IF @rueckgabe>5
BEGIN
  --do something
END

Es wird die mitgelieferte Stored Procedure “sp_executesql” verwendet, mit der der SQL-Code ausgeführt wird. Weiter wird eine interner Parameter definiert (hier @min), der auch noch als Ausgabeparameter gekennzeichnet wird. Dieser kann zurückgegeben und in der der ursprünglichen Codebasis wiederverwendet werden.

siehe MS MSDN sp_execute