DARMSTADT (je) - "Zusammen mit DL/1 kann man immerhin Extrakte aus der DL/1-Datenbank ziehen und mit SQL/DS morgen schon die Daten von gestern abfragen." So kommentiert Wolfgang Jung von der Darmstädter Software AG ironisierend die SQL/DS-Ankündigung der IBM und Edgar F. Codds dazu in der COMPUTERWOCHE Nr. 9 vom 27. Februar veröffentlichte Ausführungen.

Der mündige Anwender weiß sehr wohl, glaubt Jung zu wissen, "daß hier mit bekannter marketingtechnischer Brillanz mal wieder etwas angekündigt wird, was es schon lange gibt. Und so verfällt er auch nicht gleich der Relationenhysterie, sondern wartet ab," Mit Attacken von allen Seiten (Aktualität, Performance, Etikettierung) versucht der Adabas-Anwalt aus Darmstadt darzulegen, daß das IBM-Announcement in keiner Form am Lack des hauseigenen Datenbanksystems kratzt.

Jung: "Was Codd für eine bahnbrechende Innovation' als Ergebnis vieler Forschungs- und Entwicklungsjahre hält, ist für über 600 Adabas-Anwender in aller Welt schon seit langem Realität. Adabas-Anwender sagen bereits seit zehn Jahren Datenfeld statt Attribut, Datensatz statt Tulpe und Datei statt Relation.

Daß man relationale Anwendungen mit Adabas spielend realisieren kann, war und ist kein Grund, es als Relationenmodell zu bezeichnen; denn Adabas beherrscht ebenso hierarchische oder netzartige Anwendungen, ohne daß man es hierarchisches oder Netzwerkmodell nennt."

Unklar ist für Jung auch, was verschiedene von Codd genannte Funktionen eigentlich mit dem Relationenmodell zu tun haben. Er zählt auf: Datenschutz auf Feldebene, gezielter Schutz von Werten oder Wertebereichen bestimmter Datenfelder, automatische Sperrverfahren gegen konkurrierende Änderungen und vollautomatische Wiederanlaufverfahren auf logischer Transaktionsebene.

Ohne derartige Funktionen ist nach Jungs Auffassung moderne Datenverwaltung schon lange nicht mehr denkbar; und er äußert den Verdacht, ihre besondere Hervorhebung sei vielleicht darauf zurückzuführen, daß sie durch eine Schwergeburt nach vielen Forschungsjahren in vier Entwicklungslabors des Herstellers liebstes Kind geworden seien. Der IBM-Kritiker erinnert hier an die vier Prototypen PRTV, XRM, QBF und System R,

So vermißt Jung denn auch beim Lösungsansatz von SQL/DS ein klares modulares Konzept fortschrittlicher Datenkommunikation und sieht Komponenten miteinander vermischt, die nicht zusammengehören und die sich performancemäßig allem Anschein nach "auf den Füßen stehen dürften": Flexible anwendungsneutrale Datenverwaltung einerseits und eine mächtige Anwendungskommunikationssprache andererseits.

Jung-Kommentar dazu: "Kein Wunder also, daß Codd um die Performance-Frage wie die Katze um den heißen Brei schleicht. Offensichtlich ist, was die Anwendung von SQL/DS alleine betrifft, die alle Performance tötende 'eierlegende Wollmilchsau' entstanden."

"Es sei auch längst kein Geheimnis mehr, fährt Jung in seiner Philippika fort, daß Datenbanksysteme mit physischen Pointern in den Daten und ein echtes Feldkonzept für leistungsstarke Kommunikationssprachen unverdauliche Brocken sind.

Ziehen die Darmstädter für sich das Fazit: "Bleiben wir also ruhig und gelassen bei unserem Konzept. Es liegt keinerlei Grund vor, Adabas umzubenennen."

Und mit Blick auf ihr Kommunikationssystem "Natural" holt die Software AG zu einem letzten Schlag gegen SQL/DS aus: Codd unterscheide zwischen "Umgebungen mit hohem Performance-Anspruch, großen, relativ stabilen und vorausgeplanten Anwendungen" und Bereichen, "wo eine Vorausplanung schwierig oder unmöglich ist; beispielsweise bei rasch wechselnden Anforderungen, sondierenden Recherchen, unvermuteten Abfragen und Fragen mit simulierendem 'Was-ist-wenn . . .' - Charakter".

Hier seien Adabas/Natural-Anwender besser dran, meint Jung; denn dieser Aspekt spiele für sie keine Rolle. Natural sei schon deshalb flexibler als SQL/DS, "weil es unter voller Ausnutzung der Adabas-Datenverwaltung zu jedem Zeitpunkt direkt auf brandaktuelle Daten zugreifen kann".