Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

26.04.1991

DB2 - Fluch oder Segen?

Der Segen von Datenbanken ist weitgehend unbestritten; für die ordnungsliebende deutsche Seele ist nichts wohltuender, als die Daten aufgeräumt zu wissen. Jeder von uns hat aber auch schon den Fluch der Ordnung gespürt, wenn nach dem Großreinemachen nichts mehr zu finden war. Letztendlich haben wir es im Deutschen aber zumindest zu einer exakten Terminologie gebracht: Für uns handelt es sich eben nicht vorrangig um die "Datenbasis" wie bei den Angelsachsen, sondern um die "Datenbank". Eine Bank hat etwas Solides; es bringt Gewinn, etwas auf die Bank zu legen, jedoch Verlust, etwas herauszuholen. Genauer kann man das Dilemma des real existierenden Datenbankwesens kaum durch einen Satz beschreiben.

Technisch gesehen hat dieses Datenbankwesen eine interessante Entwicklung durchlaufen, die kaum durch Technisches erklärt werden kann, wohl aber mit Marktmacht und auch mit hypertrophem Sicherheitsbedürfnis. Die dominierende Art von Datensenke basiert auf /37(9)0-Architekturen mit MVS oder VSE als Betriebssystem. Nun gibt es weit und breit keinen Informatiker von Rang, der diese Basis-Systeme allein von der Architektur her als datenbankgeeignet klassifizieren könnte. Die Hauptmängel dieser Systeme liegen in ihrem in der Realität beschränkten Adreßraum (auch heute noch läuft ein großer Teil der Anwendungen im 24-Bit-Modus!) sowie im nachträglichen Aufpfropfen von Cache-Mechanismen im Datenbereich, die insbesondere bei fehlertoleranten Anforderungen Probleme bereiten.

Die Verteidiger des /37(9)0-Datenbankwesens führen einige Gründe für ihre Entscheidungen an:

1. Es gibt nur für diese Architektur genügend Kenner für Anwendungsentwicklung und -wartung.

2. Andere Angebote weisen nicht die nötige Stabilität auf.

3. Ein reichhaltiges Angebotsportfolio ist vorhanden.

4. Bei IBM ist man sicher aufgehoben.

5. Ein auf Datenbanken abgestimmtes Architekturkonzept , braucht es nun nicht mehr, denn MIPS werden immer billiger.

Diese Argumente lassen sich nicht in, Bausch und Bogen verdammen, aber sie lassen doch immerhin Fragen aufkommen:

1. Als vollelektronische Satzsysteme in den Redaktionen aufkamen, gab es mehr als ausreichend Bleisetzer. Setzen wir deshalb heute noch in Bleilettern?

2. Hat man vielleicht vergessen, wieviel Aufwand der Datenbankkunde in seine Programme hineinstecken mußte, um eine einigermaßen stabile Anwendung zu erreichen? Hier sei nur an gewisse Recovery-Funktionalitäten und ihre Verspätungen im IBM-Angebot erinnert.

3. Folgt aus der Breite des Anwendungsangebots auch notwendiger weise die Wirtschaftlichkeit der einzelnen Anwendung? Wer ist im Einkauf überhaupt in der Lage, bei Anwendungsangeboten auf unterschiedlichen Plattformen einen realistischen Vollkostenvergleich anzustellen, wo doch die Geschichte von Softwareprojekten eine Geschichte von Fehleinschätzungen der Einführungs- und Betriebsaufwendungen ist? Als besonders schwerwiegendes Hindernis für bessere Kaufentscheidungen stellt sich auch das mangelnde Wissen um die Kosten einer bestimmten Funktionalität im Vergleich zu ihrem Nutzen dar.

4. Die Sicherheit, die ein Lieferant bietet, kann mehr oder weniger polemisch durchleuchtet werden - aber hat nicht Sicherheit als tiefenpsychologisch, nicht sachlich begründetes Verkaufsargument mit Sicherheit einen übersteigerten Preis wie alles Unwägbare?

5. Welche MIPS werden billiger? Brutto- oder Netto-MIPS (das heißt abzüglich Overhead und zuzüglich Preis für die Basissoftware)? Ist die 137(9)0-Welt der Preisverfall-Trendsetter?

Insgesamt fällt bei den aufgeworfenen Fragen auf daß sie auf eine Wirtschaftlichkeit zielen, die weiter gefaßt ist als üblich und auch die Basissystem-Entscheidungen ins Kalkül zieht.

Bei der Analyse der DB-Landschaft drängt sich ein wenig das Bild vom erfahrenen Bergführer auf, der jeden Kunden über die Eiger-Nordwand schleppt, weil er sie am besten kennt und seinen ganzen Ehrgeiz in die Minimierung der Touristen-Aufschlagrate legt, statt sich der Mühe zu unterziehen, ein weniger mühe- und gefahrvolles Terrain kennenzulernen.

Was das alles mit DB2 zu tun hat? Nun, DB2 ist ein relationales Datenbankangebot wie viele andere auch, das durch folgende Merkmale charakterisiert ist :

DB2 kommt vom Marktführer für große DB-Basissysteme. Beim Marktführer ist zwar viel Know-how, aber wenig Ehrgeiz auf Performance-Spitzenplätze gegeben.

DB2 ist mit der 137(9)0-Architektur gekoppelt, das heißt mit einem der höchsten Preise pro Instruktion oder Transaktion am Markt.

DB2 ist an die IBM gebunden, die auch künftig einen Großteil ihrer Gewinne nicht nur mit Softwarelizenzen, sondern auch mit 137(9)0-Systemen erzielen möchte.

DB2 ist vom wichtigsten Quasi-Standard IMS ebenso weit entfernt wie alle anderen Angebote, obwohl es vom selben Hersteller wie IMS kommt.

Die aufgeworfenen Fragen mit ihren Antwortoptionen lassen somit DB2 als ein Angebot unter vielen erscheinen, das unter dem Gesichtspunkt globaler Wirtschaftlichkeit wahrscheinlich die größten Schwächen aufweist, dafür aber eher den Eindruck eines nicht zu kalten Sicherheitsbettes erweckt.

Den finanziell Verantwortlichen kann nur zu höchster Gründlichkeit bei Grundsatzentscheidungen hinsichtlich DB2 geraten werden, weil sonst leicht ein Pfad zum Kostengipfel beschnitten wird, bei dem eher der Lieferant das Tempo und die Steilheit bestimmt als der zahlende Kunde.