SQL Azure – Gehen wie auf Wolken (Teil 3)
Kommentare

Zugriff via ADO.NET und ODBC

Anwendungen können via ADO.NET oder ODBC auf die SQL-Azure-Datenbank zugreifen. Für beide Technologien sind die richtigen Verbindungszeichenfolgen entscheidend. Diese sehen

Zugriff via ADO.NET und ODBC

Anwendungen können via ADO.NET oder ODBC auf die SQL-Azure-Datenbank zugreifen. Für beide Technologien sind die richtigen Verbindungszeichenfolgen entscheidend. Diese sehen wie folgt aus und lassen sich mit der Webanwendung zur Verwaltung der SQL-Azure-Datenbank abrufen. Einzig das Kennwort muss hier noch ausgetauscht werden (Nein, mein Kennwort lautet nicht myPassword). Für ADO.NET:

Server=tcp:ierfwxs8rz.database.windows.net;Database=dotnetconsulting;User ID=tkansy@ierfwxs8rz;Password=myPassword;Trusted_Connection=False;Encrypt=True;

Für ODBC:

Driver={SQL Server Native Client 10.0};Server=tcp:ierfwxs8rz.database.windows.net;Database=dotnetconsulting;Uid=tkansy@ierfwxs8rz;Pwd=myPassword;Encrypt=yes;

Das .NET Framework bietet für das Arbeiten mit Verbindungszeichenfolgen unterschiedliche Klassen als Unterstützung: System.Data.SqlClient.SqlConnectionStringBuilder (ADO.NET) und System.Data.Odbc.OdbcConnectionStringBuilder (ODBC). Damit stellen besonders Kennwörter, die Semikolon oder andere Zeichen mit Bedeutung beinhalten, keine große Gefahr mehr für die Programmstabilität dar.

Wolken am blauen Himmel

Also alles eitel Sonnenschein in den Wolken? Mitnichten! Zwei Punkte dürften bei der Entwicklung ins Gewicht fallen. Zunächst einmal ist der Entwurf einer SQL-Azure-Datenbank mit lieb gewonnen Standardtools wie SQL Server Management Studio möglich, doch ist deren Unterstützung zurzeit noch recht eingeschränkt. Soll z. B. einen neue Tabelle erstellt werden, erscheint eine T-SQL-Textvorlage und nicht der grafische Designer, den der Entwickler bei SQL-Server-Datenbanken gewohnt ist. Dieser Punkt wurde bereits angesprochen. Der zweite Punkt wiegt leider noch schwerer. Es werden bei weitem nicht alle Funktionalitäten von SQL Server unterstützt. Insbesondere die folgenden Technologien und Werkzeuge können mit SQL Azure nicht eingesetzt werden:

  • Windows-Authentifizierung
  • SQL-CLR-Integration
  • Service Broker
  • Spartial Data Type
  • HierarchyID, Geometry und Geography
  • Partitionierung
  • Transparent Data Encrypting
  • Cross Database References
  • SQL Profiler
  • Linked Server
  • Server-Trigger

Macht eine Anwendung also von einem oder mehreren Punkten ausgiebigen Gebrauch, ist sie konsequenterweise nicht ohne weiteres auf SQL Azure portierbar. Auf längere Sicht muss dies aber kein K. O. sein, da SQL Azure von Microsoft in der nächsten Zeit mehr und mehr ausgebaut werden wird.

Alles hat seine Grenze

Zwar sagt man, dass der Horizont die Grenze sei, doch bei SQL Azure ist es bereits die maximale Datenbankgröße von aktuell 10 GB. Zwar dürfte dies für eine große Anzahl von Anwendungen ausreichend sein, doch sind 10 GB heutzutage auch nicht mehr sehr viel. Auch der Einsatz von Data Mining ist mit Vorsicht zu genießen. Die Verbindung zur Datenbank in der Cloud ist im Vergleich zu lokalen Datenbanken doch recht langsam. Außerdem kostet entstehender Netzwerkverkehr bares Geld.

Abrechnungsmodell

Die gesamte Azure-Plattform ist nach einem Lizenzmodell kostenpflichtig. Die Kosten setzen sich aus monatlichen Festkosten pro Datenbank plus verursachtem Netzwerkverkehr (ein- und ausgehend) zusammen. So ist z. B. die Grundgebühr für eine bis zu 10 GB große Datenbank zwischen 7 Euro/11 CHF (9,99 US-Dollar) und 99,99 US-Dollar fällig. Der Netzwerkverkehr schlägt nochmals mit 0,07 Euro/0,11 CHF (0,10 US-Dollar) für eingehenden und 0,11 Euro/0,17 CHF (0,15 US-Dollar) für ausgehenden Netzwerkverkehr zu Buche (in beide Richtungen jeweils auf ein Gigabyte gerechnet). Wie viel Traffic bis dato geflossen ist, kann leicht mit der folgenden Abfrage ermittelt werden:

SELECT Direction, SUM(Quantity) / 1048576 AS Quantity FROM sys.Bandwidth_Usage GROUP BY Direction;

Wobei Egress für ausgehenden Verkehr und Ingress für eingehenden Verkehr stehen. Wer über ein laufendes MSDN-Abonnement verfügt, besitzt automatisch Kontingente der gesamten Azure-Plattform, was selbstredend auch SQL Azure einschließt. Kontoauszüge, die an die E-Mail-Adresse geschickt werden, mit dem das Windows-Live-ID-Konto verknüpft ist, helfen dabei, die Übersicht über die Kosten zu behalten. Ich selbst habe ein kostenfreies Einführungsangebot für eine Vielzahl von Tests verwendet und das Limit von 500 MB bisher in keinem Monat überschritten. Aktuelle Details finden Sie auf der Windows Azure-Seite .

Fazit

Das kostenfreie Testangebot von Microsoft ist eine tolle Gelegenheit, sich die neue Cloud-Computing-Technik von Microsoft anzuschauen und sich mit ihr vertraut zu machen. Vor einer Entwicklung oder Umstellung auf SQL Azure sollte jedoch detailliert geprüft werden, ob die neue Plattform (schon) alle notwenigen Funktionen und Merkmale mitbringt. SQL Azure ist nämlich nicht gleich SQL Server und die Umstellung somit auch nicht im Handstreich getan – auch wenn der erste Eindruck und das Marketing dies gerne suggerieren möchten. Aber dennoch ist SQL Azure (mehr als) einen Blick wert!

Thorsten Kansy ist als unabhängiger Softwarearchitekt, Entwickler und Trainer für seine Kunden tätig. Wenn es seine Zeit zulässt, schreibt er zudem Bücher und Artikel rund um „seine“ Themen, der Entwicklung komplexer Anwendungen mit .NET im Microsoft-Serverumfeld, insbesondere SQL Server. Er ist als MCSD.NET, MCSD, MCPD, MCTS, MCT, MCDBA zertifiziert und sowohl in den Sprachen C# als auch VB.Net zu Hause. Sie erreichen ihn unter tkansy@dotnetconsulting.eu.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -