Regelmäßig werden Fragen gestellt wie "Was für ein Standard-Datenbanksystem steckt in allegro?" oder "Kann man eine allegro-Datenbank mit SQL abfragen?"
Man erlebt in solchen Unterhaltungen leicht, wie der eine sehr viel von relationalen Datenbanken versteht, von allegro aber ganz wenig, bzw. umgekehrt. Dann wird es mühsam und Fehleinschätzungen  sind auf beiden Seiten vorprogrammiert. Um diesem Übelstand abzuhelfen und das gegenseitige Verstehen zu fördern, wird hier der Versuch gemacht, vergleichende Aussagen zu den Konzepten und Eigenschaften der beiden Datenbankwelten zu machen, und zwar mit möglichst wenig Fachjargon und mit Blick mehr auf die Praxis als auf die Theorie. Diese "Welten" sind von höchst unterschiedlicher Größe und Bedeutung, das ist klar, doch darum geht es hier nicht, schon gar nicht um die immer nur für konkrete Anwendungen, aber nicht allgemein entscheidbare Frage "Was ist besser?" Wer aber wegen eines konkreten Projekts vor eben dieser Frage steht, soll hier Hilfen zur Einschätzung erhalten. Zudem werden de facto immer wieder relationale Daten nach allegro überführt bzw. soll Datenaustausch in umgekehrter Richtung stattfinden, und auch dabei können ein paar übergreifende Kenntnisse nützen.

Ab Version 25 gibt es vom System her eine Unterstützung für den Austausch zwischen den Welten: aresqa.
Sicher kann man noch viel mehr sagen, vermutlich müssen einige der Aussagen weiter präzisiert oder modifiziert werden. Jeder Leser ist eingeladen, konstruktive Kritik zu üben, damit wir diese Übersicht weiter verbessern können.
Für den vorliegenden Text ist Dank zu sagen an Thomas Berger (Bonn), Mathias Manecke (DB Leipzig) und Dr. Annemarie Tews (UB Leipzig) für Beiträge und Diskussionen.

Relationale Datenbank-Management-Systeme (RDBMS) und allegro, das sind recht unterschiedliche Gebilde, die man im Grunde nicht leicht vergleichen kann. Vor allem waren die Entwicklungsziele nicht dieselben. RDBMS wurden primär (doch nicht ausschließlich) entwickelt mit Blick auf solche Anwendungen, die Berechnungen und Auswertungen erfordern, also im weitesten Sinne Faktensammlungen sowie Geschäfts- und Verwaltungsanwendungen. allegro dagegen zielte von vornherein (aber auch nicht ausschließlich) auf strukturierte Textdaten; dazu gehören als Spezialfall bibliothekarische Katalogdaten. (Als eine dritte Kategorie könnte man vielleicht die Internet-Suchmaschinen betrachten wollen, die aber nur für das Retrieval in unstrukturierten Texten geschaffen wurden, nicht für die Verwaltung dieser Texte. Daher kann man sie kaum als Datenbanksysteme bezeichnen, und nur um solche geht es hier.)

Die nachfolgende Übersicht versucht, für Vertreter beider Umgebungen verständlich zu sein, stellt hauptsächlich strukturelle Aspekte gegenüber und beschränkt sich auch in dieser Hinsicht auf wenige, für Bibliothekszwecke wichtige Punkte. Für eine Einschätzung in konkreten Zusammenhängen wird man meistens noch weitere Kriterien berücksichtigen müssen, bis hin zu den Kosten, die hier außen vor bleiben. (Bibliotheken sind auf's Ganze gesehen, und kommerziell betrachtet, nur eine Nische, das darf man nicht verkennen.)
Vor Jahren hat einmal die DFG in ihren Förderrichtlinien empfohlen, Standard-Datenbanksysteme statt proprietärer (firmeneigener) Lösungen zu bevorzugen. De facto hieß das, man solle ein RDBMS einsetzen, denn andere umfangreichere und durchgesetzte Standards gab es und gibt es noch immer nicht, etwa für sog. "objektorienterte" Datenbanken. Die DFG-Empfehlung entsprang nicht einer Erkenntnis, solche Datenbanken seien die bestgeeigneten für bibliothekarische Zwecke - und bis heute hat sich das weder theoretisch noch praktisch erwiesen. Hinter der Empfehlung stand vielmehr die Hoffnung, dadurch zu herstellerunabhängigen Anwendungen kommen zu können. Idealerweise, so die Vorstellung, sollte man die Hardware und das Datenbanksystem wechseln können, ohne viel Aufwand in die Anpassung der Anwendungssoftware stecken zu müssen. Diese Hoffnung hat sich noch nirgends überzeugend erfüllt, die Abhängigkeit der Anwendungssoftware von den spezifischen Besonderheiten einer Datenbankgrundlage ist denn doch immer recht groß: insbes. hat jedes SQL seine Eigenheiten. Ist der Standard also nur vermeintlich ein solcher, oder ein zu schwacher?

Das Entity-Relationship-Modell, die Grundlage der RDBMS-Theorie und -Praxis, ist ein mathematisch fundiertes Konstrukt. Es sachgerecht anzuwenden ist eine anspruchsvolle Aufgabe. Dazu gehört die Erstellung einer sog. "normalisierten" Tabellenstruktur. Wenn RDBMS häufig eingesetzt werden, ohne auf ein schlüssiges, gründlich durchdachtes, theoretisch sauberes ER-Modell aufzusetzen, dann ist das nicht dem relationalen Konzept, sondern den Entwicklern anzulasten. Zu fragen bliebe also, ob sich bibliothekarische Sachverhalte in einem ER-Modell wirklich elegant und effizient abbilden lassen. Diese sehr komplexe Aufgabe ist wohl noch immer nicht umfassend und allgemeingültig gelöst. Noch jeder, der es versuchte, konnte erleben, wie auf diesem Gebiet viel mehr Teufel in viel mehr Details stecken als man gedacht hätte und infolgedessen viel mehr Zeit zur Umsetzung gebraucht wird als man angesetzt hatte, unerwartet viele Tabellen nötig sind und die Anwendungsprogramme deshalb unerwartet groß und kompliziert werden. Es kommt erschwerend hinzu: ein theoretisch stimmiges Modell allein reicht nicht aus. Zwar wird oft ein Modell mit einigen hundert oder ein paar tausend Datensätzen gut funktionieren, dann aber bei weiterem Anwachsen "in die Knie gehen". Es gibt manche Dinge, über die man bei kleineren Datenmengen gar nicht nachzudenken braucht, die mit Millionen Daten aber auch auf stärkster Hardware nicht mehr zufriedenstellend schnell funktionieren (z.B. "views" und vor allem "joins"). Solche Effekte, die dann leicht zu Kompromissen zwingen, sind bei allegro, so darf man aus Erfahrung sagen, weniger gravierend.

Wer bis hierher gelesen hat, kann die Fragen des ersten Satzes leicht beantworten: "Keins" bzw. "Nein". Die zugrundeliegenden Vorstellungen, was denn eine Datenbank für Eigenschaften haben und was sie leisten soll, unterscheiden sich einfach zu stark. Manche Typen von SQL-Abfragen wird man mit Hilfe der FLEX-Technik und der Parametrierung nachbilden können, nicht jedoch die gesamte Bandbreite der SQL-Funktionen. Schließlich ist SQL ausdrücklich für RDBMS geschaffen worden, allegro aber hat aus guten Gründen ein anderes Konzept. Die Erwartung, beide könnten weitgehend kompatibel gemacht werden, ist also unrealistisch. (Umgekehrt könnte man mit SQL auch nicht alles nachbilden, was man mit allegro machen kann. Z.B. das Blättern in Registern und die hierarchischen Satzstrukturen.)

Diese Übersicht macht hinreichend die Stärken und Schwächen beider Datenbankkonzepte deutlich. Hätte eines der beiden keine Schwächen, würde es entweder allegro nicht geben, oder aber die UB Braunschweig wäre inzwischen die reichste Bibliothek der Welt.
Aber Scherz beiseite: durchaus denkbar sind hybride Anwendungen, die sich der Vorteile beider Systeme bedienen. Warum nicht z.B. Katalogisierung und OPAC mit allegro, Erwerbung und Ausleihe mit einem RDBMS. Beide können über ihre Schnittstellen sowohl die andere Datenbank befragen als auch ihr Auskünfte geben! Denkanstöße in dieser Richtung kann der hier vorliegende Vergleich möglicherweise geben.

Vergleichweise noch weitaus seltener anzutreffen und in der Standardisierung noch nicht so weit fortgeschritten sind Objektorientierte Datenbanksysteme (OODB). Zu deren Grundkonzept hat allegro eine viel größere Ähnlichkeit als zum RDBMS-Konzept.

Things a library system needs 

by buss_error (142273)  on Tuesday August 22, 2000, @04:34PM (#836100)
(http://www.apnic.net/ | Last Journal: Thursday June 13, @11:02AM)

# Be able to read any of three or four dozen MARC "standards"
# Search on any word (but the stop dictionary for words such as the and to of ect.) for a word in any 
   one of over 1K places in the marc record.
# Be able to handle more than one library,
# be able to store books in different locations within the library,
# do user tracking by overdue, notes on the user, automatically import from other databases or text files, 
  have any one of several options for the user such as loan period 
  (but checks the holding to see if the standard period is longer or shorter, 
  or if the fine for overdue is less or more), be able to block a user, 
# be able to block a user based on what library they are a user for, much much more,
# be able to route books between libraries,
# be able to route books to outside vendors such as binders, restorers, storage, ect.ect.ect.
# be able to find out who checked out a book last,
# be able to change the default loan period.
# Maintain statistics on the book such as size, no. pages, language, print size, ISBN, LCCN, 
  how many times used in the library, checked out, inventoried, price, "extras" such as clear cover,
  a place for notes for the whole library system and another place for each library,
  ability to search on the note, title author, publisher, copyright date, date purchased,
  dewey, LCN cataloging or some other system, age limits for checking out.
# Keep track of budget and invoices, orders, barcodes, much much more.
# Ability to keep track of when the next magizne is due, when the subscription runs out,
   where the old copies vs. new copies are, index the mags.,
# Print reports on just about anything so throw a report generator at it.
   And if you want more, there is about five hundred pages of basic requirements in any
   book on library science. Add to that you have to know who a user is and if they are
   authorized to do any particular function, (Some can check out, but not in, others can
   add a note but not edit the book, some can edit books but not at any library except
   where they are assigned) you get the picture.

Off hand, I'd say that a good library system is about four hundred times more difficult than writing Linux. 
I know. I do Unix admin and Library systems for a living.

Trust me, this is not simple. I do think it very worthwhile though.