InfoWeek: Sie führen seit nun mehr fast 6 Jahren die Ask-Tom-Kolumne und arbeiten seit rund 13 Jahren für Oracle. Was war für Sie in dieser Zeit die faszinierendste Entwicklung im Datenbankbereich?
Tom Kyte: Das Internet hat jeden von uns überrumpelt, als es zwischen Mitte bis Ende der Neunzigerjahre explosionsartig die Welt überspannte. Statt mit Datenbanken für eine Handvoll User wie in der Client-Server-Zeit hatten wir es auf einmal mit praktisch unbegrenzten Anwenderzahlen zu tun. Wenn Sie mir vor 12 Jahren gesagt hätten, ich würde 2005 neben meiner normalen Tagesbeschäftigung noch eine Datenbank mit monatlich 115'000 Usern und 2'000'000 Transaktionen betreuen, hätte ich herzhaft gelacht. Heute ist das eigentlich recht normal.
Durch Ihre Arbeit haben Sie einen guten Überblick über die drängendsten Probleme von Datenbankentwicklern. Haben sich diese im Verlauf der Jahre verändert?
Für mich geht es im Wesentlichen immer wieder ums Design, darum, über die eigentliche Problemstellung nachzudenken. Viele der physikalischen Probleme von vor zwölf Jahren sind inzwischen gelöst. Wir verwalten Terabyte-Datenbanken. Ein gutes, solides Design ist demgegenüber eine zeitlose Aufgabenstellung. Heute wird damit allerdings eher unsorgfältiger umgegangen als früher, weil die Anwender glauben, das Design sei durch das Entwicklungsframework schon erledigt. Man steckt heute viel mehr Zeit in die Funktionalität und das User-Interface als in Sicherheits- und Skalierbarkeitsfragen.
Können Sie sich an eine Datenbankfunktion erinnern, die von den Anwendern nicht so aufgenommen wurde, wie man das erwartet hatte?
Da kommt mir «autonomous transaction» in den Sinn. Diese Funktion wurde mit Oracle 8i eingeführt. Ich war über die Möglichkeit von Untertransaktionen innerhalb einer grösseren Transaktion zum Beispiel für das Auditing zuerst begeistert. In der Praxis wurde die Funktion aber häufig sehr gefährlich eingesetzt, indem die Integrität von Transaktionen verletzt wurde.
Welches ist denn für Sie das wichtigste Datenbank-Feature?
Diese Frage kann ich sehr einfach beantworten: Das Concurrency und Consistency Modell von Oracle, das es möglich macht, dass das Lesen nicht das Schreiben blockiert und umgekehrt. Das Concurrency Model hat mich ursprünglich auch zu Oracle gebracht. Es war für mich der entscheidende Unterschied zu anderen Datenbanken. Anwender können so Anfragen stellen, ohne dass dies zu einem «blocking» oder «locking» führt. Das Datenkonsistenz-Modell bietet uns das «read consistency»-Attribut, dass ich auch das «Korrekte-Antwort-Attribut» nenne.
Was sind die häufigsten Fehler, die beim Programmieren von Datenbankapplikationen gemacht werden?
Ich habe für mich fünf Hauptfehler zusammengefasst: An erster Stelle steht, keine Bind-Variablen zu benutzen. Das ist schlecht für die Performance, für die Speichernutzung, für die Skalierbarkeit und wahrscheinlich am schlimmsten für die Sicherheit. Wenn Sie das Ausmass der damit zusammenhängenden Sicherheit-Probleme interessiert, googeln Sie einfach «sql injection».
Der zweite grosse Fehler ist, keine Testumgebung zu haben, oder eine ungenügende Datenmenge für Tests. Man kann die Antwortzeit nicht sinnvoll mit 1000 Records testen, wenn die produktive Datenbank
1 Million Records enthalten wird.
Als dritten grossen Fehler sehe ich das Fehlen eines Konfigurationsmanagements. Zu viele Leute machen einfach Änderungen und versuchen, diese dann nachträglich irgendwie zu eruieren. Ohne History, ohne Dokumentation hat man ganz einfach keine Kontrolle.
Der vierte Fehler ist der Versuch, unabhängig von der spezifischen Datenbank zu werden. Dabei wird viel Energie in das Wiedererfinden von Features ausserhalb der Datenbank gesteckt. Für mich ist das sinnlos. Gleich welche Datenbank Sie verwenden, nutzen Sie die Features, die diese Ihnen bietet!
Der fünfte Hauptfehler ist ein organisatorischer: In vielen IT-Shops sehen sich Entwickler und Datenbankadministratoren als Gegner, und das führt zu Fehlern und Ausfällen.
In den letzten Jahren versuchte man, das Business von der Technologie zu entkoppeln. Kann dies nicht auch zu Problemen führen, weil die Technologie am Ende missverstanden wird?
Es gibt immer mehr solche Probleme, indem beispielsweise in der mittleren Ebene Datenbank-Features wie Transaktionsmanagement und die Concurrency-Kontrolle noch einmal selber geschrieben werden, obwohl sie schon vorhanden sind. Daran ist allerdings weniger das «Business» schuld, das sich nicht für Technologie interessiert, als vielmehr Entwickler, die nicht wirklich verstehen, was ihre Datenbank kann.
Mit Ihrer Website imitieren Sie in einem gewissen Sinn die Open-Source-Kultur. Könnte dieser Community-Ansatz nicht noch fruchtbarer sein, wenn Oracle den Source-Code offenlegen würde?
Ich stimme insofern zu, als meine Kolumne Community-basierten Support nachahmt, aber nicht Open Source als solches. Bei Open Source gibt es neben dem Community-basierten Support genauso den zahlungspflichtigen. Community und Open Source sind nicht Synonyme.
Ich bin mir auch nicht sicher, ob dadurch zusätzlicher Input kommen würde. Wir bieten schliesslich schon sehr viele Diskussionsforen, News und andere Kanäle für Anwedner.
Vom 7. bis 9. Dezember 2005 beantwortet Tom Kyte im Zurich Developement Center Ihre Fragen. Die Workshops rund um die zentralen Themen von Datenbankentwicklern und
-Administratoren sind gemeinsame Veranstaltungen von Digicomp Academy und Oracle University.
Infos: www.digicomp.ch/tomkyte
