Während unter dem FAQ-Artikel „Was ist das Wesen der „Objektorientierung“? Woher kommt es?“ eher allgemein über Sinn und Zweck von objektorientierter Sicht der Dinge gesprochen wird, widmen wir uns vorliegend einem konkreten Einzugsgebiet der „oo“-Technologie, nämlich dem der Datenbanken und der Datenbankserver. Die objektorientierte Erfassung von Daten und deren Strukturen ist das entscheidende Momentum, das transObjects® zu den weltweit modernsten Client-Server-Technologien macht.
In dem Eingangs zitierten FAQ-Artikel diskutieren wir darüber, dass sich die objektorientierten Anwendungen grundsätzlich nach den weniger volatilen Datenstrukturen (bzw. deren Beziehungen zueinander) orientieren, als nach den Prozessen, die den Objekten dieser Strukturen, also den Daten selbst, gelten. Bereits rein von der Begrifflichkeit her drängt sich doch die Frage auf, ob denn die Ausrichtung nach Datenstrukturen beim Übergang vom Client auf den Datenbanken zwingend aufgegeben werden muss und das ausgerechnet dort, wo es per se um Daten und deren Strukturen geht, nämlich eben in den Datenbanken!???
Auf den ersten Blick ist man geneigt zu fragen, gibt’s denn das überhaupt? Und ob es das gibt! Von einem kleinen Nischenanbieter bis hin zu einem weltweiten Softwarekonzern vollführen fast alle denselben Drahtseilakt: Die Clients werden zwar – wenn wir Glück haben – objektorientiert programmiert, dann werden die abzuspeichernden Objekte auf triviale zweidimensionale Strukturen verflacht, um anschliessend in die SQL- Tabellen „gepresst“ zu werden! Die naturgemäss gegebene multidimensionale Struktur der Daten geht dabei genauso verloren, wie die ursprünglich gegebenen Beziehungen der Datenstrukturen zueinender, insbesondere die in der objektorientierten Welt selbstverständliche (Klassen-) Hierarchie. Die Fachleute sprechen hierbei von einem sog. Paradigmenwechsel.
Die Frage, die sich hieran abermals anschliesst, lautet, wozu denn so was? Sind denn namhafte Datenbankserver wirklich auf einem technischen Stand, der nichts weiter hergibt, als simple Tabellen? Soll es wirklich die einzige Möglichkeit der Strukturierung von SQL-Daten sein?
Die erste der beiden Fragen, nämlich ob dem so sei, ist mit einem klaren „Ja“ zu beantworten. Ob Sybase, Oracle oder Microsoft – sie alle bieten dem Entwickler die (fast) ausschliessliche Möglichkeit, seine Daten in Tabellen speichern und verwalten zu können, wofür sich jeder vom „C++ Club“ herzlich bedankt…😉 Die zweite Frage, nach dem „warum“, ist hingegen wesentlich schwieriger zu beantworten. Warum entzogen sich bis dato viele Datenbanken so erfolgreich dem oo-Trend?
Dieses Phänomen ist nicht monokausal zu erklären. Einer der Gründe für diese Entwicklung ist sicherlich in der Entstehungsgeschichte des SQL zu suchen. Seinerzeit – noch vor der oo-Ära – war man bestrebt, eine universelle Schnittstelle zu einer möglichst grossen Zahl von Datenbanken zu schaffen, um Applikationen, die einem gewissen Standard genügten, weitestgehend Datenbank-unabhängig zu machen. Dieses „Esperanto“ für Datenbanken bekam den Namen „Structured Query Language“; einer der bekanntesten Standards in der Informationstechnologie überhaupt war geboren! Der Haken dabei war allerdings, dass die semantischen Zwänge von SQL ein zweites Esperanto nach sich zogen, nämlich bei den Datenbank-Datenstrukturen. Auch die Tabellen waren… na ja, nicht gerade geboren, eher aus der Taufe gehoben.
Eine nicht unwesentliche Rolle dürfte hierbei Oracle zugeschrieben werden, dem Hersteller der wohl bekanntesten gleichnamigen Datenbank. Die sehr frühe und sehr dominante Markpositionierung der Oracle-Datenbanken setzte den SQL-Trend fort – und gleichzeitig die Konkurrenten mächtig unter Zugzwang. Microsoft beispielsweise versuchte es mit einer unorthodoxen Technologie erst gar nicht, sondern schwenkte ebenso auf die SQL-Schiene ein, wie nahezu alle Datenbankhersteller. Sogar Intersystems mit deren Caché-Server, der an die SQL-Paradigmen überhaupt nicht gebunden ist, schwimmt voll im Trend mit und bietet brav eine SQL-Schnittstelle an. Von „SQL-Objekten“ ist dort die Rede1. Währenddessen blieb vielen Herstellern von objektorientierten Datenbanken, die sich dem SQL nicht genügend öffneten, der Markterfolg mehr oder weniger versagt; Object Design oder Poet können ein Lied davon singen.
In der Tat sind marketingtechnische Belange mindestens genauso ausschlaggebend für die „Beständigkeit“ des SQL, als die Standardisierung, die ohnehin nur partiell gelang oder auch die fast schon sprichwörtliche Unflexibilität von einmal fertig implementierten SQL-Strukturen. So gesehen ist es allzu verständlich, dass sich die hoffnungsvollen Blicke der oo-Community eben auf die SQL-Platzhirsche á la Oracle oder Microsoft richten, die bereits die ersten Ansätze hin auf ein Durchbrechen des alten SQL-Korsetts haben durchblicken lassen: Ob es nun das XML ist oder Tabellenhierarchien bzw. ineinander eingebettete Tabellen – all das hat unübersehbar Züge von multidimensionalen Datenstrukturen. Allerdings warnen wir vor allzu hohen Erwartungen. SQL-Datenbankserver sind von vorne herein eben fürs SQL konzipiert und (nur) hierauf bestens getrimmt. Andere Strukturen entsprechen nicht gerade deren Naturell und werden folglich wohl immer nur einen Kompromiss darstellen; etwa ein Amphibienfahrzeug, das für bergiges Gelände tauglich gemacht worden ist: Kann es ein guter Offroader werden?
Die Frage, die sich zumeist an die vorherigen Erläuterungen angeschliesst, lautet, was denn so schlimm sei an diesem Paradigmenwechsel, wo doch viele namhafte Softwarelösungen damit (scheinbar) bestens zurechtkommen? Nun, ein kurzer Blick auf die Kostenstrukturen solcher Lösungen ist da sehr aufschlussreich. So mancher Anwender hat sich schon mal gefragt, warum er denn für eine massvolle und völlig legitime Mutation an seinem R/3 Spezialisten aus Walldorf für einen solch langen Zeitraum unter (nicht gerade billigen) Vertrag nehmen muss? Und warum sind weitere Anpassungen ein schier aussichtloses und unbezahlbares Unterfangen?
Gewiss sind die exorbitanten Kosten von R/3 nicht alleine mit dem Paradigmenwechsel Java/SQL2 zu erklären, aber die extrem hohen Maintenance-Aufwendungen dieses Systems gehen zu einem nicht unbeträchtlichen Teil hierauf zurück. In einem demnächst erscheinenden FAQ-Artikel auf unserer Website wenden wir uns anhand einer Fallstudie anderen Problemen rund um SQL zu.
________________________
1 SQL-Strukturen sind ein Spezialfall der Oo-Strukturen – genauso, wie zweidimensionale Tabellen ein Spezialfall von multidimensionalen Gebilden sind. Denn während das SQL mit tabellarischen Abbildungen (Zuordnungen) von ASCII- oder Unicode-Strings arbeitet und somit
(im Sinne des kartesischen Produktes) gilt, gibt es bei den multidimensionalen Datenbanken – so auch bei Caché – diese Beschränkung nicht mehr. Vielmehr gilt:
wobei dieses selbstverständlich einer realen Einschränkung unterliegt, genauso wie es die Längen der Strings logischerweise tun.
2 Sofern es das überhaupt gibt, denn die Umschreibung des R/3 von der proprietären und rein prozeduralen Sprache ABAP kann mehr oder weniger vollzogen und eher weniger als mehr gelungen sein…