Die zweitschönste Nebensache der Welt

SQL:2003 sei Dank für eine Menge Zeit, die ich letzte Woche sparen konnte. Schuld daran waren vor allen "MERGE", aber auch eine mit "GENERATED ALWAYS AS IDENTITY" definierte Identitätsspalte.

Es wäre schon viel Schreib- und Testarbeit gewesen ohne "Merge" eine Tabelle mit Daten aus einer anderen zu aktualisieren. Das Einfügen neuer Zeilen wäre ja noch eine leichte Übung gewesen, aber für die Modifikation bereits vorhandener Zeilen habe ich bisher stets ein Programm schreiben müssen.

Das hat sich mit der aktuellen Version des SQL-Standards geändert: Nun ist es mit einer SQL-Anweisung möglich Daten in bestehenden Zeilen zu aktualisieren bei gleichzeitiger Erweiterung der Tabelle um neue Datensätze. Ich verwende "Merge" auch dann, wenn ich nur Daten zu bestehenden Schlüsseln ändern will.

Nun ist das so eine Sache mit den SQL-Standards: Viele sinnvolle Vorschläge sind in den aktuellen Versionen der gängigen Datenbanksystemen nicht umgesetzt. Das betrifft SQL:1999 und auch SQL:2003. Andererseits versuchen einige DBMS-Hersteller durch proprietäre Ergänzungen der Datenbankfunktionalität Kunden an sich zu binden. Das betrifft vor allem Oracle, aber leider auch MySQL.

Interessant! Sehr große Tabellen scheinen MySQL an den Rand der Verzweiflung zu bringen. Diese Erkenntnis verdanke ich nicht eigener Praxis, sondern Bernds leidige Erfahrung:

"Ich trau aus Erfahrung keiner MySQL-Tabelle größer als 5 GB ..."

Hm, eigentlich sollten 5 oder 8 oder 10 GB keine Herausforderung für heutige DBMS sein, wohlgemerkt als Größe einer Tabelle. Solche und wesentliche größere Tabellen kommen in den besten Unternehmen vor.

Fragt man Vertreter von IBM oder Oracle danach, ob ihre DBMS diese Herausforderung bestehen, so werden sie gelangweilt mit Achseln zucken und "So what" fragen. Die wirkliche Herausforderung liegt im Terabyte-Bereich. Bis Bernds Tabelle den erreicht, fließt noch viel Wasser den Neckar herunter.

Möglicherweise wird er bereits davor seine Datenbank in ein anderes DBMS migriert haben.

... die kostenfreie Express-Variante des SQL Server 2005 installieren: Das geht nicht!. Zumindest nicht unter XP, immerhin mit SP2.

Ständig hat das Setup etwas zu meckern: Mal fehlt das .NET Framework 2.0, mal passt ihm der vorhandene Windows Installer nicht. Als Setup hat man es schon schwer.

Da lobe ich mir DB2 und gerade die - auch kostenfreie - Express-C. Dort wird alles installiert, was benötigt wird, ohne Aufforderung, zuerst dies oder das zu installieren.

In Sachen SQL Server Express bin ich mir nicht mal sicher, dass nach erfolgreichem Setup die Datenbank auch arbeitet. Denn ich habe in diesem Rechner 2 GB RAM, und Microsoft beschränkt die Nutzung für die Express auf 1 GB. Muss ich jetzt 1 GB aus dem Rechner reißen? Oder beschränkt Express künstlich den verfügbaren Speicher für die Datenbank.

Auch in diesem Falle hat die DB2 Express-C einen klaren Vorteil: Hier liegt die Schranke auf 4 GB RAM. Dagegen sind die freien DBMS-Varianten von Oracle und Microsoft mit all ihren Beschränkungen Kinderkram.

Bis kurz vor Ende lief alles ganz gut mit dem Artikel über die angekündigte Informix-Appliance. Aber dieser letzte Satz, musste der sein?

"Diese Rolle war jedoch umstritten, da IDS gegenüber der DB2-Entwicklung ein Schattendasein fristete und das mit Version 10.0 eingeführte letzte größere Update schon seit Februar 2005 zurückliegt."

Welche "Rolle" ist hier eigentlich unerheblich, die Begründung allerdings ist sehr fragwürdig.

Die Annahme des "Schattendasein" von IDS gegenüber DB2 mag eine Zeit lang als nicht völlig unbegründet gegolten haben, ist allerdings inzwischen widerlegt. Heute klingt eine solche Behauptung wie Oracle-Propaganda.

Richtig kraus ist die Begründung mit einer zweijährigen Wartezeit für die kommende IDS-Version. Ja, es gibt Software, für die es jährlich (oder häufiger) ein Update gibt. Es gibt aber auch Beispiele mit regelmäßig längeren Zyklen. Windows Betriebssysteme sind prominente Beispiele. Die Spanne zwischen XP und Vista beträgt immerhin mehr als 5 Jahre.

Eigentlich sollte ich mich nicht durch Oracle's Marketinggetue provozieren lassen. Performance als das Thema der Oracle 11g, erstmals schneller als spezialisierte Dateisysteme? Beeindruckend?

Sicher nicht, solange Oracle mit seinem Vergleich mehr Fragen aufwirft als Antworten gibt. Gegen welches Filesystem wurde gemessen? Woher kamen die Daten aus der Datenbank? Von einem Raw Device oder gar aus dem Cache? Letzteres wäre schon fast Betrug.

Trotzdem: Es ist ja bekannt, dass Oracle Marketing schon oft mehr versprochen hat, als Oracle Software halten konnte.

Also: Abwarten und auf die Details zu den versprochenen Performance-Verbesserungen abwarten. Und dann gibt es ja noch TPC.

Das Gleiche gilt für die Aussagen zur verbesserten Kompression in der 11g.

Und wie sieht es mit insgesamt 482 neuen Features aus? Beeindruckend? "Mit wie vielen kann man wirklich was anfangen?" fragte Bernd.

Also: Abwarten und auf die Liste der Neuerungen warten.

Eine Neuerung scheint aber zu fehlen: Die konsequente Integration von XML so, wie es DB2 9 vermag. Es sieht also so aus, dass die armen, unschuldigen XML-Dokumente weiterhin vor der Speicherung in eine Oracle-Datenbank zerrissen und zerfetzt werden.

Während ich mich gestern abend, kurz vor Mitternacht, noch mit Pivot-Tabellen (nein, nicht mit Excel) beschäftigte, poppte mein Feed-Reader mit der Meldung "Oracle releases 11g database beta" noch. Überraschung! Verursacher ist ein Beitrag in "The Register" von gestern, 20.35 GMT.

Danach verbessert Oracle mit der 11g seine Kompressionstechnik. Man darf gespannt darauf sein, was genau dahinter steckt, und wie die Oracle-Kompression nun im Vergleich zu der von DB2 9 ausfällt.

Im IDG-Testbericht zur DB2 9 vermerkte der Redakteur zum Thema "Kompression":

"All the same, if I had to pick one feature that puts DB2 ahead of any of the other databases, this would definitely be the one, because it's going to be far more useful to the largest portion of the client base. I would imagine that Oracle and Microsoft are both scrambling to be the next to bring this to market."

Schafft also Oracle den Anschluß noch vor Microsoft?

Anlässlich der "Information on Demand"-Konferenz verkündet IBM erste Erfolge bei der Kundengewinnung mit DB2 9.

"Hundreds of customers across different industries have already embraced DB2 9 and many are moving their databases from Oracle to IBM’s new data server, including: American Electric Power, Central Michigan University, Farmers Insurance and Teleglobe."

Dabei sollen vor allem die neue Features wie Kompression und XML-Unterstützung für den Sinneswandel ausschlaggebend gewesen sein.

Ich bin bei solchen Meldungen erst mal skeptisch. Erfolge im Wettbewerb werden langfristig in Zu- oder Abnahme von Marktanteilen gemessen. Warten wir also die nächsten Gartner- oder IDC-Studien ab. Auch wenn ich von diesen Studien nicht viel halte, Bewegungen am Markt werden sie hinreichend reflektieren.

Sicher, die neuen Features von DB2 9 sind aus technischer Sicht überzeugend, aber reicht das, um alte, eingeschworene Oracle-Anwender zu einer in der Regel aufwändigen Migration zu bewegen?

Ob DB2 9 auch aus geschäftlicher Sicht gegen Oracle überzeugt, wird wohl mühsam im Einzelfall in PoCs nachgewiesen werden müssen.

Es ist tatsächlich nicht so, dass die IT-Presse nicht lernfähig wäre. Einige Monate nach dem katastrophalen Ausrutscher des CW-Ressortleiters ue, hat die CW indirekt die Aussagen ihrer "Kenner der Datenbankszene" revidiert.

Die CW-Muttergesellschaft IDG hatte die neue DB2-Version in ihrem Labor getestet und für hervorragend befunden.

So purzeln nun wie selbstverständlich folgende absolut korrekte Erkenntnisse aus der CW-Feder:

"Statt wie bisher XML als Blob (Binary Large Object) zu speichern oder XML-Struktur auf relationale Strukturen abzubilden, speichert pureXML die XML-Datei selbst - mit all ihren Eigenschaften und ihrer hierarchischen Struktur."

Na also, das habe ich ja schon immer gesagt.

Als erstes Resultat seiner Zusammenfassung der IDG-Testergebnisse kommt der Autor (ba) zu einem erfreulichen Ergebnis:

"Alles in allem ist die neue DB2 technisch imposant. Sie ist voll gestopft mit Funktionen, die Administratoren und Entwickler gleichermaßen freuen."

Aber das ist noch nicht alles ...

DB2 9 bietet viele Verbesserungen gegenüber den Vorversionen und auch gegenüber konkurrierenden DBMS, vor allem in Sachen Performance und TCO. Diese Neuerungen werden ausführlich in einem Bloor Research "White Paper" von Philip Howard beschrieben.

Immer wieder dieser PH. Dass er nicht nur Gutes über DB2 9 schreibt, sondern auch schon mal über Oracle Elaborate (warum bloss) zeigt sein Artikel "Oracle rebuilds Warehouse".

Doch zurück zu DB2 9 mit einigen Kernaussagen aus dem White Paper:

"First, I think this leaves Oracle and Sybase (as the two vendors with the best current handle on XML) well behind the curve, with Microsoft and the others more or less out of sight. What this release will allow you to do is to build applications that handle both XML and relational data much more easily, without losing any of the richness that this implies, and without degrading performance."

Dies schrieb Philip Howard in "The Register" bereits im Dezember 2004 zur XML-Unterstützung in DB2 Viper im Vergleich zu anderen DBMS. Daran hat sich bis heute nichts geändert, weder Oracle noch Microsoft haben bisher nachgezogen.

Geändert hat sich nur der Name, die Viper hat nun Produktstatus und heißt DB2 9. Apropos Namensgebung, dazu schreibt Howard in seinem White Paper "The business benefits of DB2 9"

"The “Viper” release of IBM DB2, which is officially version 9, is the most important release of this database for many years. Indeed, IBM regards Viper as so significant that, at one time, it considered calling it DB3, on the basis that this represents the third generation of databases from IBM, following IMS and DB2."

Die "2" macht schon Sinn wegen der zwei zugrundeliegenden Paradigmen: hier das relationale Modell, dort der XML-Standard.

Immer wieder kann man lesen oder hören, dass Beörden oder andere öffentliche Organisationen ihre Daten in Oracle Datenbanken speichern und verwalten.

Als braver Steuerzahler (und das nicht zu knapp) stört mich das erheblich!

Das stört mich seitdem ich weiß, dass hier unnötig Steuergelder mit der aufwändigen Administration von Oracles DBMS verschleudert werden. Beim Einsatz effizienterer und performanterer Datenbanksysteme kann man schon mal bis zu einem Drittel der Administratorenkosten sparen. Und das ist noch nicht alles.

Darum sollten sich mal die diversen Rechnungshöfe kümmern.

Ein Papier mit diesem Titel wurde auf der diesjährigen Informix Infobahn verteilt. Ich habe bereits daraus zitiert. Aber nicht nur deshalb ist der Vergleich von Jacques Roy so interessant, dass ich das "Papier" als PDF hier abgelegt habe.

Als Verantwortlicher ("Technical Leader, WorldWide Data Services") für die IDS-Entwicklung gibt Jacques Roy einen tieferen Einblick in das Zusammenspiel von Hardware, Betriebssystem und Datenbankserver-Architektur. Besondere Freude scheint es ihm bereitet zu haben, mit einigen Mythen um Oracles RAC aufzuräumen.

... und wieder neue Gerüchte.

Die Software-Branche ist ein Haifischbecken. Die Großen fressen die Kleineren und lassen sich das viel kosten.

Und immer wieder tauchen die Namen IBM und Oracle auf. Die balgen sich auf dem Transfermarkt für Software-Hersteller immer wieder um kaufwillige Kandidaten. Noch sieht es so aus, dass IBM den Kampf um Filenet gewonnen hat. Ich nehme allerdings an, dass Larry Ellison hier noch nicht aufgegeben hat. Eine kleine Chance hat er ja noch.

Nachdem Cognos immer noch eigenständig ist, geht es nun offensichtlich um Business Objects. Beide würden mit dem Kauf ihre Marktposition in Bereich "Business Intelligence" (mir leuchtet immer noch nicht ein, wie Unternehmen intelligent sein können) vor allem gegenüber Microsoft stark verbessern.

Bei IBM würde ein Kauf von BO eine Änderung ihrer bisherigen Middleware-only Strategie bedeuten. Cognos oder Microstrategy wären dann nicht mehr Partner, sondern Konkurrenten.

Sowohl IBM als auch Oracle würden mit der BO-Software ihre BI-Produktpalette zum Frontend hin komplettieren.

Diese "Empfehlung" kann man in Oracles SQL-Referenz finden:

VARCHAR Datatype

Do not use the VARCHAR datatype. Use the VARCHAR2 datatype instead. Although the VARCHAR datatype is currently synonymous with VARCHAR2, the VARCHAR datatype is scheduled to be redefined as a separate datatype used for variable-length character strings compared with different comparison semantics.

Leider wird ihr mehr oder weniger fröhlich gefolgt. Man gebe nur "VARCHAR2" als Google-Suchbegriff ein und staune.

Glücklicherweise ist SQL eine standardisierte Sprache. Dazu gehört die Definition von Standard-Datentypen. VARCHAR ist einer. VARCHAR2 ist Oracles Erfindung und hat nichts mit dem Standard zu tun.

Was könnte Oracle veranlassen, seine zahlenden Kunden aufzufordern vom Standard abzuweichen? Der angegebene Grund kling doch sehr ominös. Will Oracle in Sachen VARCHAR auch vom Standard abrücken? Warum wird VARCHAR2 nicht für die geplanten Erweiterungen verwendet?

Jacques Roy zitierte am 19.10.2005 aus Oracles "Oracle Database 10g: The Self-Managing Database". Dieses Papier ist nicht mehr aktuell. Es gibt nun seit Juni dieses Jahres "Oracle Database 10g Release 2: The Self-Managing Database". Dort heißt es im Original:

"The Oracle database server provides a number of initialization parameters to optimize its operation in diverse environments. Only a few of these parameters need to be explicitly set as the default values for the rest of them are adequate in vast majority of cases. In Oracle Database 10g the parameters have been categorized into basic and advanced categories. Administrators will be able to restrict their day-to-day interaction with about 30 basic parameters. ..."

Mit Release 2 sind also 2 Parameter dazugekommen. So sieht Fortschritt a la Oracle aus.