Archiv der Kategorie: SQL Server

T-SQL Abfrage für Tags

Gerade musste ich eine etwas schwierigere Auswertung machen. Die Aufgabenstellung dazu war:

“Ermittle alle Kunden, die weder der Branche Handel noch Verbraucher zugeordnet sind.”

Nun muss man wissen, dass wir die Branchen an einem Kunden quasi wie Tags haften. Im ERP sieht das so aus:

image

Dementsprechend gibt es zw. der Tabelle Kunde und Branche eine n:m Beziehung. Ein Kunde kann keinen Tag, nur einen oder mehrere haben. Ein Tag kann wiederum keinem Kunden, genau einem oder mehreren zugeordnet sein. Gemäß der Normalisierungsregeln für relationale Datenbanken ist die Tabelle Branchen so aufgebaut, dass z.B. für das oben genannte Beispiel 4 Einträge zu dem Kunden mit der ID 7001 drin stehen. Pro Tag jeweils einen Eintrag.

Das schwierige war nun, dass ich den kompletten Kundenstamm durchlaufen und für jeden gefundenen Kunden eine Unterabfrage feuern musste, die prüft, ob in irgendeinem der zugeordneten Tags der Begriff Handel oder Verbraucher vorkommt. Im Programmcode wäre das eine klassische For Each Schleife, welche im inneren nochmal eine For Each Schleife enthält (Anmerkung: Wenn man sich mit LINQ auskennt, geht es auch einfacherSmiley).

Wie macht man das nun mit T-SQL am einfachsten, wenn man zu faul ist zum Programmieren? Nachdem ich mich mit dem Wissensvermittler meines Vertrauens (Google) beraten habe, war die eleganteste und einfachste Lösung das Verwenden des Befehls

For XML Path(“)

Ein konkretes Beispiel findet ihr hier :

SELECT p1.CategoryId,
     
( SELECT ProductName + ‚,‘
          FROM Northwind.dbo.Products p2
         WHERE p2.CategoryId = p1.CategoryId
         ORDER BY ProductName
           FOR XML PATH(“) ) AS Products

  FROM Northwind.dbo.Products p1
GROUP BY CategoryId ;

In der erzeugten Spalte steht dann der XML String. Bei uns sah das so aus:

<Beschreibung>Maschinenbau </Beschreibung><Beschreibung>Anlagenbau/ Apparatebau</Beschreibung>

Nun konnte ich mit LIKE prüfen, ob in diesem z.B. Handel oder Verbraucher steht.

Werbeanzeigen

SQL Datenbank sichern–richtigen Haken setzen!

Wer eine SQL DB über Task – Sichern sich z.B. als Quelle für eine Test-DB sichert, sollte den Haken “Kopiesicherungen” setzen. Warum?

>>Eine Kopiesicherung ist eine SQL Server-Datensicherung, die unabhängig von der Sequenz von herkömmlichen SQL Server-Sicherungen erstellt wird. Normalerweise wird beim Erstellen einer Sicherung die Datenbank geändert, und außerdem beeinflusst dies die Art und Weise, wie spätere Sicherungen wiederhergestellt werden. Manchmal kann es sich jedoch als nützlich erweisen, eine Datensicherung für einen bestimmten Zweck vorzunehmen, ohne die allgemeinen Sicherungs- und Wiederherstellungsprozeduren für die Datenbank zu beeinflussen. Zu diesem Zweck sind in SQL Server 2005 Kopiesicherungen möglich.<<

>>Nach einer Kopiesicherung wird das Transaktionsprotokoll nie abgeschnitten. Kopiesicherungen werden in der is_copy_only-Spalte der backupset-Tabelle aufgezeichnet.<<

Quelle

SQL Datenbank kopieren

Hier eine Anleitung in Form von Screenshots, wie man auf einem MS SQL Server 2008 R2 eine Datenbank kopiert. Ab welcher Version es diese Funktion direkt integriert gibt, weiß ich nicht. Falls ihr die Funktion also nicht finden solltet, müsst ihr den Umweg über Sichern und Wiederherstellen (Anbinden) gehen. Beachtet dazu auch den nachfolgenden Blogeintrag!

Im Kontextmenü auf einer Datenbank auf Task und dann Datenbank kopieren klicken. Danach dieser Anleitung folgen.

image

image

image

Achtung: Hier habe ich die Kopie auf den gleichen Server gemacht. Normalerweise macht man sich eine Kopie auf den Testserver. Wichtig wäre in diesem Fall, dass der Quellserver Zugriff auf den Zielserver hat!

image

Da man normalerweise die Live-DB kopieren will, sollte man zu Methode zwei greifen Zwinkerndes Smiley

image

image

Da ich die Ziel DB schon gelöscht hatte, verwende ich Option 1. Normalerweise benötigt man Option 2.

Danach 2x auf Weiter klicken. Achtet im letzten Dialogfenster auf folgendes:

image

Das ist das Konto mit dem auf den Zielserver zugegriffen wird.

SharePoint Testserver: Inhaltsdatenbank aktualisieren

Da man in der Regel immer einen Testserver betreibt, habe ich eine kurze Anleitung geschrieben wie man die Inhaltsdatenbank aus dem Live System in das Testsystem kopiert.

Der Ablauf ist wie folgt:

1. Löschen der bisherigen Inhaltsdatenbank auf dem Testserver über Zentraladministration –> Anwendungsverwaltung –> Inhaltsdatenbanken verwalten. Wählt rechts oben die passende Webanwendung aus. Dann klickt ihr auf die Datenbank. Hier gibt es ganz unten die Option “Inhaltsdatenbank entfernen”. Aktiviert den Haken und klickt auf Ok. Merkt euch den Namen der Datenbank, da ihr diesen in Punkt 4 noch benötigt.

2. Kopiert euch die aktuelle Datenbank vom Live Server. Am einfachsten geht das mit dem SQL Management Studio. Falls ihr euch damit nicht auskennt, dann googelt kurz. Dazu gibt es genügend Einträge. Kopiert die Sicherung auf den Testserver.

3. Beendet auf dem Testsystem im IIS-Manager den Anwendungspool, der mit der Webanwendung verbunden ist.

4. Startet den SQL Dienst auf dem Testserver neu

5. Löscht die immer noch im SQL Server vorhandene Datenbank (den Namen habt ihr euch aus 1 gemerkt) mit dem Management Studio. Aktiviert die Option “Bestehende Verbindungen schließen” im Dialog (optional).

6. Stellt die gesicherte Datenbank wieder her.

7. Startet den Anwendungspool wieder.

8. Geht in der Zentraladministration wieder unter Inhaltsdatenbanken verwalten und wechselt auf die richtige Webanwendung. Klickt auf “Inhaltsdatenbank hinzufügen” und gebt den Datenbankserver und den Datenbanknamen an.

 

Wichtig:

  • Das funktioniert natürlich nur, wenn die entsprechenden SQL Anmeldungen, die auf dem Live-System vorhanden sind, auch auf dem Testsystem sind.
  • Die zwei Server müssen auf dem gleichen Patch-Stand sein.
  • Passt bei absoluten Links auf, da ihr sonst wieder im Live-System landet. Immer relative Links nutzen. Am besten stellt ihr das Farbschema auf dem Dev um, dann merkt ihr sofort, wenn ihr plötzlich die Plattform wechselt.

XML-Datentyp im SQL Server

In meinem Artikel zu DTOs beschrieben habe, lassen sich Datenobjekte sehr leicht als XML serialisieren. Ich habe das Konzept aufgegriffen und zur Datenhaltung von Konfigurationen verwendet. Die XML Daten speichere ich in einer dedizierten DB-Tabelle (die Tabellenstruktur hierfür werde ich in einem späteren Blogeintrag veröffentlichen). Jetzt musste ich mir überlegen, welchen Datentyp ich für die entsprechende Spalte mit den XML Werten verwende: Nehme ich varchar(max) oder XML.

XML als vollwertigen Datentyp gibt es bereits seit SQL Server 2005. Da wir SQL Server 2008 R2 einsetzen, wäre es also durchaus zu erwägen. Um eine sondierte Entscheidung treffen zu können, habe ich mir ein SQL Server 2008 Buch (nicht R2!) zur Hand genommen. Zunächst einmal einige Vorteile:

  • Constraints &  Indizes können darauf erstellt werden
  • Setzen eines Defaultwertes ist möglich
  • Validierung gegen ein im SQL Server hinterlegtes Schema
  • Ausführung von in SQL-Befehlen eingebettetes XQuery

Hört sich zunächst einmal ganz gut an. Nun aber ein gravierender Nachteil, der zumindest für den SQL Server 2008 gilt (bzgl. R2 kann ich keine Aussage machen, allerdings glaube ich nicht, dass sich etwas geändert hat):

Wegen der binären Speicherung können XML Dokumente nicht zu 100% identisch erhalten werden, sodass etwa Leerzeichen entfernt und die Reihenfolge der Attribute verändert werden.

Nun ja, bei einer Config-Tabelle ist dies vielleicht nicht wesentlich von Bedeutung, aber wenn exakte Kopien eines XML Dokumentes z.B. aus rechtlichen Gründen benötigt werden, dann wäre dies keine Option. Diese Information, auch wenn Sie vielleicht zunächst einmal nicht relevant für meine technischen Anforderungen ist, stieß mir doch ein wenig auf. Hinzu kommt, dass die Vorteile für mich keine zwingende Notwendigkeit sind.

To make a long story short: Ich entschied mich beim Persistieren von Konfigurationsdaten, die als XML vorliegen, für den Datentyp varchar(max).

%d Bloggern gefällt das: