• Einführung
• Welche Optionen gibt es für die Entwicklungsarbeit?
• Was wollen Entwickler?
• Wie unterschiedlich sind die Editionen
• Wirkt sich die Wahl auf die verwendeten Tools aus?
• LocalDB
  • Vorteile von LocalDb für die Entwicklung
  • Nachteile von LocalDb für die Entwicklung
• Welche anderen Editionen gibt es?
  • Express Edition
  • Developer Edition
  • Web, Standard, und Enterprise Edition
  • Azure SQL Database
• Containerized Version einer beliebigen Edition
• Abschluss

Einführung

Als Entwickler brauche ich eine SQL Server-Datenbank, mit der ich Code entwickeln und testen kann. Es gibt mehrere Optionen, aus denen man wählen kann, und verschiedene Aspekte, die man beachten muss. In diesem Artikel befassen wir uns mit den verschiedenen Möglichkeiten und den Entscheidungen, die Sie treffen müssen. Die LocalDb-Edition von SQL Server wurde geschaffen, um die offensichtliche Edition für Entwickler zu sein; macht diese Idee in der Praxis Sinn und welche alternativen Vorteile bieten die anderen Editionen für Entwickler?

Für die Entwicklungsarbeit werden normalerweise mehrere Serverinstanzen benötigt. Sollen diese auf einem Server gemeinsam genutzt werden, oder auf mehrere Server oder virtuelle Maschinen verteilt werden? Sollten alle Entwicklungsserver die gleiche Edition haben? Ist es ratsam, sich auf eine Internetverbindung zu verlassen, um alle Entwicklungsserver in der Cloud zu betreiben, oder gibt es einen Platz für den traditionellen “SQL Server auf dem Laptop”?

Vor SQL Server 2005 war es nicht schwer, die Edition zu wählen, mit der man entwickeln wollte. Außer dem Produkt selbst gab es nur eine kostenlose Entwickler-Edition. Mit der Einführung von Containern in Windows 2016 und SQL Server 2016 ergeben sich für Entwickler einige interessante Möglichkeiten.

Welche Optionen gibt es, die für die Entwicklungsarbeit genutzt werden können?

Die gibt es derzeit:

• Express Edition
• Developer Edition
• Web Edition
• Standard Edition
• Enterprise Edition
• LocalDb
• Azure Datenbank + Amazon RDS
• Containerisierte Version einer beliebigen Edition

Es gibt auch eine Edition namens Compact Edition, die veraltet ist, aber noch verfügbar ist. Sie weist einige Ähnlichkeiten mit SQL Server auf, hat aber einen sehr kleinen Footprint und wird prozessintern ausgeführt. Compact Edition führt einen SQL-Dialekt aus, ist aber keine Edition von SQL Server. Es ist wirklich keine geeignete Entwicklungsinstanz für die Entwicklung und das Testen von Code, der auf SQL Server bereitgestellt werden soll.

Was wollen Entwickler?

1. Produktivität
   Ich bin als Datenbankentwickler am produktivsten, wenn ich meine eigene Instanz auf meinem eigenen Rechner habe, die ich nach Belieben anhalten, starten, löschen und erstellen kann. Wenn sich die Datenbank oder die Instanz auf einem gemeinsam genutzten Server befindet, finde ich, dass die Entwicklung langsamer ist – entweder ändern andere Leute Dinge, an denen ich arbeite, oder sie tun andere Dinge, die einen eigentlich schnellen Entwicklungs-, Einsatz- und Testzyklus unterbrechen.
2. Einfachheit
   Ein Entwickler sollte seine Zeit mit dem Schreiben, Testen und Debuggen von Code verbringen können, und jede Zeit, die er mit der Verwaltung von Ressourcen wie SQL Server-Datenbanken verbringt, bedeutet, dass er weniger Zeit für die Dinge hat, die tatsächlich nützlich sind und dem Unternehmen einen Nutzen bringen.
3. Genauigkeit
   In einer idealen Welt hätte jeder Entwickler eine schnelle, lokale, exakte Nachbildung der Produktion mit Daten, die den Produktionsdaten so nahe wie möglich kommen. Damit können sie testen, ob sich ihre Änderungen in der Produktion genauso verhalten wie in ihrer Entwicklungsumgebung. Es gibt sicher zahllose Anwendungen, die auf einem Entwicklerrechner superschnell funktionieren, aber langsamer sind, wenn sie in einer 3-Schichten-Architektur mit vielen Latenzzeiten und Netzwerkaufrufen zwischen den Diensten eingesetzt werden. Es ist auch wichtig zu überprüfen, ob der Code, den Sie für eine Datenbank schreiben, tatsächlich auf einer anderen Datenbank läuft. Wenn Sie SQL Server 2008 R2 in der Produktion einsetzen, wäre es sinnlos, mit SQL 2016 zu entwickeln und dabei In-Memory-Tabellen zu verwenden.

Wie unterscheiden sich die Editionen?

Beim Entwickeln und Testen einer Datenbankanwendung ist es oft wichtig zu wissen, dass wir, wenn wir Code schreiben und sehen können, wie er sich in der Entwicklung verhält, ein ähnliches Verhalten in der Produktion erhalten werden. Die Editionen werden durch die installierten und aktivierten Funktionen definiert; der Code in der Core-Engine ist derselbe, egal ob Sie eine der kostenlosen Editionen oder die Enterprise Edition verwenden. Das Problem entsteht, wenn Sie z. B. eine reine Unternehmensfunktion in der Entwicklung verwenden, aber nur eine Instanz der Standard-Edition in der Produktion haben. Der vollständige Vergleich dieser Editionen wird von Microsoft hier veröffentlicht: “Features Supported by the Editions of SQL Server 2016”

Wirkt sich die Wahl auf die verwendeten Tools aus?

Alle Instanzen verhalten sich in Bezug auf die Core-Engine und die Sprache gleich; wenn Sie also ein Tool haben, das die Enterprise-Edition verwalten kann, kann es im Prinzip auch jede andere Edition verwalten. In der Vergangenheit haben sich nicht alle Tools an dieses Prinzip gehalten: Es gab einmal eine Version von SQL Management Studio für SQL Express, die nicht in der Lage war, die Funktionen der vollständigen Edition zu verwalten. Jetzt ist das SQL Server Management Studio rückwärtskompatibel zu früheren Versionen und seitwärtskompatibel zu allen Editionen. Es steht derzeit als kostenloser Download zur Verfügung, so dass Sie jede Instanz verwalten können, ohne eine Volllizenz zu benötigen.

Die zweite Einschränkung besteht darin, dass Sie für die Verwendung von LocalDb die SQL-Client-Bibliothek ändern müssen, so dass ältere Versionen von SQLOLEDB und .Net keine Verbindung herstellen können – wenn Sie eine Anwendung haben, die in .net geschrieben wurde, die älter als Version 4 ist, kann sie sich nicht verbinden.

Welche Editionen stehen zur Auswahl?

LocalDb

Wenn Sie keine speziellen Anforderungen haben, die LocalDb nicht erfüllen kann, dann muss es die erste Wahl für Entwickler sein. Schauen wir uns an, was es ist und welche Vorteile es bietet.

LocalDb ist eine abgespeckte Version von SQL Server, die speziell entwickelt wurde, um leichtgewichtig und einfach zu starten und schnell zu beenden zu sein. Dies bedeutet einen Kompromiss, so dass es einige Einschränkungen gibt, aber es ist wirklich eine gute Wahl für die meisten Entwickler, weil Sie schnell erstellen, verwenden und zerstören Instanzen, die speziell für einen bestimmten Benutzer sind.

LocalDb hat einige zusätzliche Vorteile: Sie verwendet dieselben Binärdateien für jede Instanz, so dass Sie nicht für jede benötigte Instanz viel Speicherplatz benötigen. Das bedeutet, dass es sehr einfach ist, eine Instanz zu starten, wenn Sie in der Hitze einer Entwicklungssitzung eine neue Instanz benötigen.

Die Erstellung einer neuen LocalDb ist einfach: Sie geben einfach Folgendes in die Befehlsshell ein:

Dadurch wird eine neue Instanz mit dem Namen “instance name” erstellt, die Sie verwenden können, Auf meinem Rechner dauert es etwa 4 Sekunden, um eine neue Instanz zu erstellen, und dann noch einmal etwa 2 Sekunden, um die Instanz zu starten. Die Installation einer neuen Instanz eines anderen SQL Server-Typs wird in Minuten bis Stunden gemessen.

Wenn Sie mehrere Versionen von LocalDb installiert haben, können Sie jede dieser Versionen ganz einfach erstellen, indem Sie diesen Code in einer Befehlsshell ausführen:

Sie erhalten eine Liste wie:

Wenn Sie dann eine 2012er Instanz benötigen, würden Sie Folgendes eingeben:

Sie erhalten dann eine neue SQL Server 2012-Instanz, mit der Sie eine Verbindung herstellen können.

Die Verbindung zu LocalDb ist etwas anders als die Verbindung zu einer Standardinstanz: Anstatt sich mit dem Rechnernamen zu verbinden und entweder einen Port oder einen Instanznamen zu übergeben, geben Sie das Wort “(localdb)” und dann den Instanznamen an, d.h. wenn die Instanz “test-instance” heißt, würden Sie dies als Servernamen übergeben:

Um herauszufinden, welche Instanzen Sie haben, können Sie verwenden:

Dies listet die LocalDb-Instanzen auf, um eine weitere zu untersuchen, geben Sie den Instanznamen im letzten Befehl ein, z.B.:

Die Ausgabe wird ist

• der Name
• Version
• der Benutzer, dem sie gehört
• ob sie gestartet wurde oder nicht
• die letzte Startzeit

wenn sie gestartet wurde, gibt er auch den Pfad der benannten Pipe an, auf der er läuft. Wenn Sie einen Client haben, der den (localdb) Servernamen nicht versteht, können Sie sich vielleicht über Named Pipes mit der Instanz verbinden.

LocalDb ist großartig für die Entwicklung, weil es so schnell ist, Instanzen zu erstellen und zu starten, wenn Sie oft an verschiedenen Projekten arbeiten, können Sie Instanzen stoppen und starten und viele verschiedene Instanzen zur Verfügung haben, ohne den Overhead, sie zu pflegen und auf der Festplatte zu speichern. Sie haben natürlich die gleichen Nachteile wie Express, da es sich um abgespeckte Versionen von SQL Server handelt. Es gibt z.B. keine Volltextindizierung, was den Einsatz in einigen Anwendungen verhindern kann.

Vorteile von LocalDb für die Entwicklung:

• Schnelle Entwicklung, es ist einfach, neue Instanzen für Entwicklung und Tests zu erstellen.
• Gemeinsame Nutzung von Binärdateien durch alle Instanzen der gleichen Version, so dass Sie nicht viel Speicherplatz benötigen oder viele verschiedene Versionen pflegen müssen

Nachteile von LocalDb für die Entwicklung:

• Enthält keine grundlegenden Funktionen wie SQL Agent
• Unterstützt keinen FILESTREAM
• Kann kein Merge Replication Subscriber sein,
• Erlaubt nur lokale Warteschlangen für Service Broker.
• läuft immer unter dem Sicherheitskontext des Benutzers;

Welche anderen Editionen gibt es?

Express Edition

Die Express Edition ist eine kostenlose Version von SQL Server, die für kleine Datenbanken mit einer geringen Anzahl von Benutzern gedacht ist. In der Version 2016 ist Express auf vier Kerne, 1 GB Arbeitsspeicher pro Instanz und eine maximale Datenbankgröße von 10 GB beschränkt. Obwohl dies eine vernünftige Größe ist, ist sie für die meisten Produktionsdatenbankanwendungen nicht groß genug, aber sie ist für die Entwicklungsarbeit nützlich, wenn Ihre Entwicklungsinstanz nicht viele Ressourcen benötigt und klein ist und wenn Sie keine Funktionen entwickeln, die von Standard- oder reinen Enterprise-Funktionen abhängen.

Vorteile von Express für die Entwicklung:

• Performance-Probleme treten bei der Entwicklung deutlicher zutage
• Es gibt keine Lizenzkomplikationen bei der Entwicklungsarbeit
• Es eignet sich sowohl für die individuelle als auch für die gemeinsame Entwicklung.
• Netzwerkdienste können wie bei den Vollversionen konfiguriert werden, so dass man sich mit tcp von entfernten Rechnern verbinden kann und der SQL-Browser-Dienst Verbindungen über den Instanznamen zulässt
• Es kann frei heruntergeladen und installiert werden

Nachteile von Express für die Entwicklung:

• Enthält nicht den vollen Funktionsumfang einer der Produktionsversionen
• Erfordert eine vollständige Standardinstallation, um eine neue Instanz zu erstellen, was Zeit für die Installation und das Upgrade und ziemlich viel Speicherplatz pro Instanz benötigt
• Sollte nicht für Last- oder Leistungstests verwendet werden

Developer Edition

Die Developer Edition ist eine voll funktionsfähige Enterprise Edition von SQL Server, bei der alle Einschränkungen aufgehoben sind. Das ist großartig, wenn Sie eine Anwendung entwickeln, die die Enterprise-Edition verwendet, aber wenn Sie eine Anwendung entwickeln, die die Standard-Edition verwendet, können Sie feststellen, dass Sie eine bessere Leistung als in der Produktion erhalten oder dass Sie eine Funktion verwenden, die nur für Unternehmen geeignet ist. Es kann ein kostspieliger Fehler sein, Code zu entwickeln und dann festzustellen, dass er bei der Bereitstellung nicht ausgeführt werden kann.

Wenn Sie an einer einzelnen Datenbankanwendung arbeiten und diese auf einem vorhandenen Server bereitstellen, der die Enterprise-Edition verwendet, können Sie nicht viel falsch machen, wenn Sie die Entwicklungs-Edition von SQL Server verwenden.

Die Lizenzierung für SQL Server 2000 bedeutete, dass die Entwickler-Edition kostenlos war, solange sie für Entwicklung und Tests und nicht als Produktionsdatenbank verwendet wurde. Hätten Sie sich entschieden, die Developer Edition für die Produktion zu verwenden, wäre der Preis für die Enterprise Edition fällig geworden. Mit dem Erscheinen von SQL 2005 wurde die Lizenzierung so geändert, dass für die Nutzung der Developer Edition eine geringe Gebühr von 50 Dollar pro Entwickler anfiel. Das bedeutete, dass viele Leute nicht in der Lage waren, die Entwicklerversion zu nutzen, vor allem in Teams, in denen die Entwickler SQL nur selten verwendeten oder in denen sie keine MSDN-Abonnements hatten, die den Entwicklern eine Lizenz für die Entwicklerversion zur Verfügung stellten. Dies war vor allem in Nicht-.net-Teams zu beobachten, die zufällig SQL Server verwendeten.

Im Lizenzierungshandbuch für SQL Server 2016 heißt es: “SQL Server Developer Edition darf nicht in einer Produktionsumgebung oder mit Produktdaten verwendet werden” – wenn man davon ausgeht, dass “Produktdaten” “Produktionsdaten” bedeutet, scheint es nicht möglich zu sein, eine Produktionsdatenbank zu sichern und wiederherzustellen, um sie zu testen, es sei denn, Sie lizenzieren den Server als Produktionsserver. Der Leitfaden besagt auch, dass die Entwickler-Edition kostenlos verwendet werden kann, wenn Sie dem “Dev Essentials”-Programm beitreten – wenn Sie eine andere Edition wie Enterprise oder Standard zum Entwickeln/Testen benötigen, können Sie über ein “Visual Studio”-Abonnement auf diese zugreifen.

Vorteile der Developer-Edition für die Entwicklung:

• Die Developer-Edition ist eine vollwertige Enterprise-Edition. Wenn Sie also testen und der Code auf der Developer-Edition funktioniert, sollte er sich genauso verhalten wie auf Ihrem Enterprise-Produktionsserver.

Nachteile der Developer-Edition für die Entwicklung:

• Nur für die Entwicklung einer Datenbank für die Enterprise-Edition geeignet. Da einige der Funktionen und Verhaltensweisen der Developer Edition in der Web oder Standard Edition fehlen, wird Ihr Produktionssystem weniger Funktionen haben als Ihre Entwicklungsumgebung, was nie eine gute Idee ist.
• Es verbraucht ziemlich viel Speicherplatz pro Instanz
• Die Lizenzierung ist nicht eindeutig, so dass eine Überprüfung mit Ihrem Microsoft-Lizenzierungsbeauftragten erforderlich ist

Web-, Standard- und Enterprise-Editionen

Diese Versionen benötigen alle eine Lizenz, um in der Produktion verwendet zu werden. Sie können die Web-Edition nur über Anwendungs-Hosting-Anbieter erwerben. Es ist oft am sichersten, mit der Edition von SQL Server zu entwickeln, mit der Sie arbeiten werden, vor allem für Leistungs- und Skalierungstests, aber nicht für die tägliche Entwicklung. Wie bereits bei der Development Edition erwähnt, ist die Lizenzierung etwas unklar und Sie müssen möglicherweise für eine Lizenz bezahlen, um eine dieser Editionen in einer Entwicklungs- oder Testumgebung zu verwenden.

Die Web Edition ist nicht allgemein verfügbar und Sie müssen normalerweise Lizenzen dafür über einen Hosting-Provider erwerben, was zusätzliche Komplexität bedeutet.

Vorteile der Produktions-Editionen für die Entwicklung:

• Sie entwickeln und testen in einer Umgebung, die der Produktionsumgebung ähnlich ist, was für Entwickler fast immer von Vorteil ist.

Nachteile der Produktions-Editionen für die Entwicklung:

• Erfordert eine vollständige Standardinstallation, um eine neue Instanz zu erstellen: Dies erfordert Zeit für die Installation und das Upgrade und ziemlich viel Speicherplatz pro Instanz
• Die Lizenzierung ist nicht eindeutig und muss mit dem Microsoft-Lizenzierungsbeauftragten geklärt werden

Azure SQL Database

Die Verwendung von Cloud-Anbietern für das Hosting von Datenbanken kann für die Entwicklung und das Testen sehr sinnvoll sein, hat aber auch einige Nachteile. Abgesehen vom Preis, den Sie für die Nutzung zahlen müssen, müssen Sie sich auch darüber im Klaren sein, dass die Latenzzeit zwischen Ihrem Rechner und der Datenbank in der Regel deutlich höher ist als bei einer lokalen oder sogar LAN-lokalen Instanz. Außerdem benötigen Sie eine dauerhafte Verbindung zur Datenbank, so dass es unwahrscheinlich ist, dass Sie abends im Zug eine Arbeit fertigstellen können.

Für reine Entwicklungsarbeiten, bei denen Sie ständig Änderungen bereitstellen und Skripte ausführen, ist dies wahrscheinlich nicht ideal, aber für Tests können sie sehr nützlich sein, insbesondere als Teil automatisierter Testsuiten, die in gehosteten Anbietern wie Appveyor oder VSTS ausgeführt werden.

Die Möglichkeit, eine neue Instanz zu erstellen, Ihren Code bereitzustellen und Ihre Tests auszuführen, ist für einen kontinuierlichen Integrationsprozess (ci) von großem Nutzen, so dass Sie mehrere Builds gleichzeitig ausführen können, ohne für jeden Build eine eigene Instanz oder Datenbank pflegen zu müssen – sobald Sie dazu übergehen, einen einzigen Build als Teil Ihres ci-Prozesses zu verwenden, ist dieser einfache Ansatz für die Bereitstellung von Datenbanken wirklich hilfreich.

Vorteile von Azure SQL Database für die Entwicklung:

• Einfachheit bei der Einrichtung neuer Datenbanken, zumal dies automatisiert werden kann
• Keine Wartung Ihrer Entwicklungsinstanzen, also kein Patching, keine Backups usw.

Nachteile von Azure SQL Database für die Entwicklung:

• Mehr für Tests als für die Entwicklung geeignet, da eine dauerhafte Verbindung erforderlich ist und diese langsamer ist als die lokale Entwicklung
• Sie müssen pro Minute der Datenbanknutzung bezahlen

Containerisierte Version einer beliebigen Edition

Windows 2016 und SQL Server 2016 bieten beide Unterstützung für die Ausführung von SQL Server in einem Container. Dadurch erhalten wir die gleiche Flexibilität wie mit LocalDb und Azure+AWS, um Instanzen schnell zu starten und zu stoppen. Wir sollten auch die Vorteile sehen, dass wir nicht jede Instanz einzeln patchen müssen, solange wir gemeinsame Images für unsere Instanzen verwenden.

Windows 2016 ist jetzt veröffentlicht worden, so dass wir jetzt potenziell Instanzen von SQL Server (sicherlich SQL Server 2016) ziemlich einfach erstellen und wegwerfen können, wenn wir Windows 10 oder Windows 2016 haben. Wenn wir an eine frühere Version von Windows oder eine frühere Version von SQL Server gebunden sind, ist es möglicherweise nicht so einfach, ein funktionierendes Image zu erstellen.

Wenn sich Container in Windows durchsetzen, sollte dies bedeuten, dass wir neue Instanzen erstellen und Instanzen ohne den langwierigen Installationsprozess starten und beenden können. Zum jetzigen Zeitpunkt scheint es, dass das Starten und Stoppen von Instanzen langsamer ist als bei LocalDb.

Wenn Sie Ihre Datenbanken in einer Cloud-ähnlichen Umgebung wie dem Microsoft VSTS-Dienst testen, werden Sie vielleicht feststellen, dass das Starten einer LocalDb-Instanz machbar ist, da sie bereits installiert ist. Im Gegensatz dazu könnte das Herunterladen des SQL Server 2016-Datenbank-Images und das anschließende Starten zu viele Ihrer Build-Minuten in Anspruch nehmen.

Fazit

Wenn wir Code für SQL Server-Datenbanken entwickeln, haben wir als Entwickler drei Hauptanforderungen:

• Wir wollen so schnell wie möglich produktiv sein;
• Wir wollen, dass unsere Umgebung so einfach wie möglich ist;
• Wir wollen nicht unbedingt auf eine gute Internetverbindung angewiesen sein;
• Wir möchten eine Testversion verwenden, die die reale Welt in Bezug auf die Funktionalität simuliert (nicht unbedingt die Leistung für die tägliche Entwicklung)

LocalDb ist in der Regel die Lösung für die meisten SQL Server-Entwickler, und wenn Sie keine speziellen Anforderungen haben, die die Verwendung von LocalDb unmöglich machen, würde ich es sehr empfehlen.