Die Aufgabenbereiche von Entwicklern und DBAs im Wandel

In den letzten paar Jahren haben sich für Entwickler in der Arbeit mit Datenbanken eine Reihe radikaler Veränderungen ergeben. Das zeigt sich beispielsweise in den veränderten Verantwortlichkeiten von DBAs und Entwicklern. Hier ein Überblick über die Auswirkungen dieser Veränderungen auf den Entwicklungsprozess.

Vergangenheit

Während der Client-/Serverjahre gestaltete sich die Rolle des DBA als eine Mischung aus Systemadministrator (mit Spezialisierung auf den Support von Datenbanken) und Entwickler (Erstellen verschiedener Ansichten, gespeicherter Prozeduren, Funktionen et cetera zur Verwendung durch Anwendungen). Der DBA musste wissen, wie man Hardware und Betriebsystem-Konfigurationen optimiert, um die bestmögliche Leistung zu erzielen. Außerdem musste er zahlreiche Tricks wie Tabellenpartitionierung, sorgfältige Erstellung von Indizes und Optimierung beherrschen, um die beste Performance aus einem System zu holen. Zudem war der DBA für Sicherheitsfragen verantwortlich. Eine seiner täglichen Aufgaben bestand darin, gespeicherte Prozeduren zu erstellen, die einen äußerst eingeschränkten Zugriff auf Datenbanken erlaubten, um der Anwendung dann nach Bedarf Zugriff auf diese Prozeduren zu gewähren und die zugrunde liegende Tabelle gesperrt zu halten.

Die Entwickler waren dagegen in der Regel von den DBAs abhängig. Der DBA hatte umfassende Zugriffsrechte auf die Datenbank und gab den Zugriff für Anwendungen und Benutzer nur bei Bedarf frei. Er wollte dem Entwickler auf keinen Fall die Möglichkeit zugestehen, eine Datenbank zu gestalten, da Entwickler dafür bekannt sind, nicht unbedingt die brillantesten Entscheidungen hinsichtlich des Datenbankdesigns zu treffen. Darüber hinaus versuchten die DBAs, die Möglichkeiten der Entwickler einzuschränken, benutzerdefinierte SQL-Befehle auf die Daten anzuwenden. Das lag daran, dass der SQL-Code von Entwicklern oft eine schlechte Performance aufwies, da sie in puncto Datenbanken nicht so versiert waren wie die DBAs.

In vielen Unternehmen gab es solche Unterscheidungen und unterschiedlichen Positionen jedoch nie. Manche IT-Abteilungen gewährten den Entwicklern freien Zugriff auf die Datenbanksysteme, und in anderen Fällen waren Entwickler gleichzeitig DBAs, während die Server-Spezialisten sich um den Rest kümmerten. In größeren Unternehmen war die genannte Arbeitsteilung jedoch weit verbreitet und wurde lange Zeit vorausgesetzt.

Heutige Situation

Es sind unzählige Entwicklungsframeworks und Systeme herausgekommen, die es Entwicklern nun viel leichter machen, vernünftigen Code für die Datenbanken zu verwenden. Verschiedene Systeme erlauben es Entwicklern nun endlich, mit richtig parametrisierten Code für Datenbanken zu arbeiten (zum Beispiel Visual Studio 2005), anstatt SQL-Anweisungen als Zeichenfolgen aneinanderzureihen, wodurch das System Angriffen durch Einschleusung von SQL-Befehlen ausgesetzt würde. Gleichzeitig erschien eine Reihe von Systemen (zum Beispiel Berichterstellung/Data Warehousing/BI), die ihren eigenen SQL-Code generierten; die Ergebnisse dieser Systeme waren oft gleichwertig oder besser, als das, was der Durchschnittsentwickler erstellen konnte. Manuelle Optimierung durch Menschen mit den entsprechenden Fähigkeiten kann den generierten Code oft verbessern, aber für die meisten Fälle funktioniert er bereits ausreichend gut.

Systeme zur objektrelationalen Abbildung (ORM/Object-Relational Mapping) wie Hibernate und .NET Entity Framework haben große Fortschritte gemacht und der Datenbank eine zusätzliche Abstraktionsschicht hinzugefügt und diese weiter verdeckt. Es lässt sich sehr viel leichter mit ORMs arbeiten, wenn der Entwickler freien Zugriff auf die Datenbank hat und sich nicht mit zugriffsbeschränkenden gespeicherten Prozeduren herumschlagen muss. Die .NET-Komponente LINQ to SQL und AREL von Rails sind weitere Beispiele für Systeme, die Entwicklern das direkte Arbeiten mit der Datenbank im Gegensatz zum Arbeiten anhand von gespeicherten Prozeduren sehr erleichtern.

Die größte Neuerung ist jedoch die Einführung verschiedener agiler Entwicklungstechniken. Die Spezifikationen von Projekten (und damit auch die Datenbankmodelle) können sich heutzutage mit jedem Kundenanruf ändern. Man arbeitet zwei Wochen lang intensiv an Anwendungen, statt wie früher sechs Monate einzuplanen. In einem kleinen agilen Team kann nicht darauf gewartet werden, dass ein DBA das Datenmodell aktualisiert und die gespeicherten Prozeduren, Ansichten etc. ändert, damit sich dann die Entwickler an die Arbeit machen können. In solchen Projektumgebungen erstellen und packen Entwickler die Datenbanken oft selbst und überlassen die Änderungen an der Datenbank einem automatischen Deploymentprozess.

Ausblick

Bedeutet das, dass der traditionelle DBA nun überflüssig ist? Wahrscheinlich nicht. DBAs werden nach wie vor gebraucht, aber sie verlieren in einer Reihe von Unternehmen definitiv ihren Status als „Hüter des heiligen Grals“, und wahrscheinlich wird die Zahl solcher Unternehmen weiter steigen.

Datenbanken weisen nach wie vor sehr ungewöhnliche Performance-Charakteristika auf und nur erfahrene Fachleute können Systeme so planen und optimieren, dass sie die höchstmögliche Leistung bringen. Davon abgesehen bestehen noch unzählige Installationen älterer Anwendungen. Außerdem erfordern Umgebungen, in denen viele Anwendungen auf eine gemeinsame Datenbank zugreifen, einen DBA als Koordinator (oft muss er auch gespeicherte Prozeduren mit ausreichenden Sicherheitsvorkehrungen für Transaktionen schreiben). Er sorgt dafür, dass die Anwendungen sich nicht in die Quere kommen. Es ist eine Sache, wenn eine einzelne Anwendung keine strengen Dateneinschränkungen für ihre eigenen Daten hat. Müssen aber zum Beispiel andere Anwendungen ebenfalls auf die Daten zugreifen, sieht die Sache schon ganz anders aus. Solche Einschränkungen sind ein gutes Beispiel für Dinge, die Entwickler im Gegensatz zu DBAs gern übersehen. Der Bereich Entwicklung verändert sich rasant und viele Aufgabenbereiche sind davon betroffen. DBAs, Entwickler und PMs stehen dabei ganz oben auf der Liste.