Moderne Datenbanken im Vergleich
Jonglieren - nur was für Artisten? - Handelt es sich um mehr als eine Handvoll Bälle oder Keulen, die mit träumwandlerischer Sicherheit absolut kollisionsfrei zu balancieren sind, kommt auch der größte Akrobat ins Schwitzen. Ganz anders soll es sich da beim Jonglieren mit Daten auf dem Computer verhalten.
Datenbanken, die Jongleure der Kilo- und Megabytes, sollen quasi ohne Training und vor allem auf Kommando, die tollsten Kunststücke vorführen können. Diesem Ziel haben sich die Entwickler der drei Datenbanken ..1st-Base", "TWIST* und "Phoenix" verschrieben. In wieweit sie ihren eigenen Ansprüchen gerecht werden, soll dieser Artikel durchleuchten.
Doch schon beim ersten Durchblättern der Handbücher stellt man schnell fest, daß vor der Fingerakrobatik erst die Verbalakrobatik beherrscht sein will: Begriffe wie BLOBs, Schlüssel, Masken, Reports, Felder oder Indizes mögen in anderen Zusammenhängen durchaus geläufig sein, doch dienen Indizes nicht nur dazu, um auf den Index gesetzte Videos zu verwalten.
So versuchen alle drei Kandidaten in ihren Handbüchern den Einsteiger anhand eines kleinen Beispiels mit der Materie vertraut zu machen, bevor es dann ans Eingemachte geht.
1st-Base
1st-Base, unser einziger nicht relationaler Kandidat, legt eindeutig den Schwerpunkt auf ein leicht zu erstellendes Datenbankdesign mit hoher Ausführungsgeschwindigkeit. Dafür müssen die Daten aber komplett in den Speicher passen, was die Zielgruppe dann deutlich einschränkt. Hier sind klar die privaten Anwender angesprochen, die sich den Funktionsumfang ihrer Adreß-, Video- oder CD-Verwaltung nicht von "fertigen" Produkten diktieren lassen wollen. Immerhin lassen sich auch schon auf einem 1-MB-Rechner einige hundert Datensätze verwalten, was wie gesagt für den Heimbereich durchaus ausreicht. Dadurch muß sich 1st-Base aber auch mit den fertigen Adreßverwaltungen etc. messen lassen, die es im Shareware-und PD-Bereich zuhauf gibt. Sicherlich kann man mit 1st-Base flexibler auf eigene Sonderwünsche eingehen, allerdings sollte man den Programmieraufwand auch hier nicht unterschätzen.
Durch den Verzicht auf grafische Gestaltung, Feldformate und -attribute konnte das Tabellen- und Masken-Layout in einem Dialog zusammengefaßt werden. Man setzt hier lediglich ein neues Feld in die Eingabemaske und bestimmt dann Feldnamen und -typ. Außerdem gehören hierzu noch die Rechnungen für eine eventuelle Einschränkung des Wertebereichs wie auch die Vorbelegung eines Feldes. So einfach und intuitiv das zugrundeliegende Konzept auch ist, so schlecht ist dessen Implementierung. Schuld daran ist nicht nur die eigenwillige Tastatursteuerung: via Return-Taste geht es erst von einem Textfeld zum anderen. Beim letzten Textfeld angekommen, wird dann je nach Dialogbox, aber ohne grafischen Hinweis (Default-Knopf mit stärkerer Umrahmung), die OK-Taste ausgelöst oder auch nicht. Die inzwischen etablierten Tastaturkürzel mit der Alternate-Taste sind 1 st-Base fremd.
An vielen Stellen, wo man heute üblicherweise Pop-Up-Menüs mit ausführlichen Texten findet, verlangt I st-Base nach einer kryptischen Nummer, die man zuvor mühsam aus dem Handbuch klauben muß. Insgesamt wirkt die Bediensteuerung wie der fehlgeschlagene Versuch, das Programm komplett mit der Tastatur steuern zu können, was bei der angestrebten Klientel wohl nicht auf ein positives Echo stoßen wird.
Die Reports sind das wahre Highlight von 1st-Base. Mit Hilfe einer BASIC-ähnlichen Programmiersprache inklusiver Schleifenkonstrukte bleibt kein Report-Wunsch unerfüllt. Auf diesem Gebiet haben die Mitbewerber noch großen Nachholbedarf. Doch alles hat seinen Preis: Von WYSIWYG (What you see is what you get) ist die Report-Programmierung mit den endlosen Kolonnen von "PRINT"-Befehlen weit entfernt.
TWIST II
TWIST, in der stark überarbeiteten Version 2, ist nach langen Wehen (bereits auf der CeBIT gab es eine erste Beta-Version zu sehen) nun endlich spruchreif. Auffallendste Neuerung sind die 3D-Objekte auf Farbsystemen. Gegenüber den anderen beiden Kandidaten nachgezogen hat TWIST jetzt auch bei den mehrzeiligen Textfeldern mit Wortumbruch, so daß jetzt nur noch die BLOBs (Binary Link Objects = eingebundene Binärdaten) auf der Wunschliste stehen.
Besonderes Schmankerl der mehrzeiligen Textfelder, die sich wie ein Editor verhalten: auch hier greifen die Cut-, Copy- und Paste-Funktionen. Die Sound- und die Grafikeinbindung sind über externe Dateien gelöst, es wird also nur der Dateiname gespeichert und nicht das ganze Bild oder der meist ebensolange Sound. Hierbei können Bilder sowohl in der Maske als auch in einem weiteren Fenster erscheinen.
Ebenso neu sind die komprimierbaren und virtuellen Felder. Damit ließe sich zum Beispiel unsere Testdatei auf 1/3 reduzieren. Virtuelle Felder sind Felder, die physikalisch nicht abgespeichert werden, sondern jedesmal vor der Anzeige in einer Maske oder Tabelle berechnet werden. Damit verhalten sie sich gegenüber dem Anwender zwar wie "normale" Felder, deren Werte berechnet werden, benötigen allerdings keinen Diskettenplatz.
Erweitert wurde TWIST auch um eine Ähnlichkeitssuche, die bei Schreibfehlern aushilft und auch beim Suchen von relatierten Feldern funktioniert.
Neu ist auch der Zugriffsschutz auf Datensatzebene mit optionaler Datenkodierung. Den größten Jubel dürften allerdings die erstmalig unterstützen Relationen auslösen. Damit kann man nun endlich nach Gusto auf Felder fremder Datenbanken zugreifen und selbstverständlich mit ihnen rechnen, oder man benutzt sie einfach als Basis für weitere Sprünge. Als einziger Testkandidat bietet TWIST hierbei Verbundmasken, kann also Daten fremder Datenbanken in der Maske anzeigen, verändern oder erzeugen, ohne daß diese Daten in der zur Maske gehörenden Datenbank auch gespeichert sein müssen. Das bringt einen enormen Bedienungskomfort und vermeidet Datenduplikate.
| Hersteller/Distributor | Victor Soft | Maxon Computer | Application Systeme Heidelberg |
|---|---|---|---|
| Preis | 249,- | 298- | 398- |
| Grenzwerte | |||
| Max. Datensätze/DB | abhängig von RAM | 4 Milliarden(3) | 2 Milliarden(3) |
| Max. Felder/Satz | abhängig von RAM | 255 | 32 000 (3) |
| Max. Feldgröße | 32000 | 32767 | 100 000 000 (3) |
| Max. Indizes/Datei | 0 | 1000 (TOS-abhängig) | 32 000 (3) |
| Feldtypen | |||
| Text (Größe) | 32 KB | 32 KB | 32 KB |
| Zahl | # | # | # |
| Ganzzahl | # | # | # |
| Fließkomma | # | # | # |
| Datum/Zeit | #/# | #/# | #/# |
| BLOB | - | - | # |
| Sound/Grafik | -/- | HSN/GEM, IMG | SAM/GEM, IMG |
| Feldattribute | |||
| Indizes | - | # | - |
| Primärschlüssel | - | - | # |
| Mußfelder | - | # | # |
| allg. Relationen | - | # | # |
| Relationen mit Verbundmasken | - | # | - |
| Komprimierte Felder | Standard | # | - |
| Virtuelle Felder | - | # | - |
| Masken | |||
| Wertetabellen | statisch | statisch | dynamisch |
| GDOS-Fonts | - | # | # |
| Schriftattribute | - | # | # |
| Graf. Elemente | - | # | # |
| Farbe | - | # | # |
| Prog. Buttons | - | - (Auslösen von Reports) | # |
| Regeln | # | # | # |
| Trigger | # | # | # |
| Sound | - | HSN (mit und ohne DMA & Falcon) | SAM |
| Grafik | - | GEM, IMG | GEM, IMG |
| Zugriffsschutz Satz/Feld | -/- | #/#(1) | #/# |
| Vordefinierte Anzeige | |||
| Tabelle | # | # | # |
| Datensatz | # | # | # |
| Reports | |||
| Rechnen | # | # | Aufsummieren |
| WYSIWYG | - | # | - |
| GDOS-/Speedo-Fonts/Attribute | -/-/# | #/#/# | -/-/# |
| Datenaustausch | |||
| Import | ASCII | ASCII, ASCII-Position | ASCII-Sätze hinzufügen und/oder ändern |
| Export | ASCII | ASCII, ASCII-Position | ASCII |
| Sonstiges | |||
| Viele-zu-Viele-Relationen (n:m) | - | indirekt | indirekt |
| Verbundmasken | - | # | - |
| Netzwerk/Multitasking | -/- | -/- | #/# |
| Zugriffsschutz | - | # | # |
| Beurteilung | |||
| Handbuch | o | + | + |
| Bedienung | o | ++ | + |
| Programmierung | - | + | ++ |
| Reports | + | ++ | + |
| Formulare | o | + | ++ |
| GEM-Einbindung | - | ++ | ++ |
| Geschwindigkeit | ++ | +,++(2) | - |
++ sehr gut, + qut, o ausreichend, - schlecht, -- sehr schlecht, # vorhanden, - nicht vorhanden, »sehr groß
[1] Über 1:1-Relation mit kodierter Datenbank lassen sich auch bestimmte Felder schützen.
[2] Wenn Daten-Cache aktiv
[3] theoretische Werte, in der Praxis nicht ausnutzbar
Integritätsregeln beschränken sich bei TWIST auf die Möglichkeit, daß beim Löschen eines Datensatzes auch der verbundene Datensatz gelöscht wird. Demgegenüber besteht die Möglichkeit, die Datenbankstruktur und die Relationen auch mit bereits vorhanden Daten im Betrieb zu verändern.
Auf liebgewonnene Gewohnheiten wie das automatische Reorganisieren der Daten im Falle eines Redesigns der Datenbank oder den integrierten Texteditor muß man bei TWIST II natürlich auch nicht verzichten.
Erfreulich ist auch, daß TWIST bei all den Neuerungen seine Geschwindigkeit beibehalten hat. In einigen Fällen wurde TWIST sogar schneller, so wurde die Suchgeschwindigkeit auf Felder ohne Index nahezu verdoppelt. Das Besondere an TW IST ist hierbei, daß Datenbestände, die kleiner sind als der freie RAM-Speicher, automatisch im Speicher gecacht werden. TWIST erreicht dabei Geschwindigkeiten, die 1st-Base sehr nahekommen und übertrifft diese in einigen Punkten sogar. Die Daten sind dabei aber immer auf der Platte gespeichert, so daß kein Risiko eines Datenverlustes besteht.
Dem Import, der zwar neben dem reinen ASCII-Import durch den positionsabhängigen ASCII-Import glänzt, sollte man noch beibringen, daß Datensätze nicht nur hinzugefügt, sondern auch ersetzt werden können, wenn die Eindeutigkeit eines indizierten Feldes verletzt wird.
An Report-Funktionen stehen dem Anwender gleich zweierlei Konzepte zur Wahl: Die Serienbrieffunktion erlaubt den im eigenen Editor erstellten formatierten Fließtext mit den typischen Epson-Druckoptionen (elite, pica, fett, schmal, ...). angereichert mit zu vor ausgewählten Feldern aus der Datenbank. Die Alternative ist die die Konstruktion eines Reports mit Feld- und Textobjekten auf einem Arbeitsblatt, die zum Beispiel bei der Erstellung von Labels vorzuziehen ist. Im Report bietet TWIST (wie auch direkt in der Datenmaske) ca. 65 Rechenfunktionen, u.a. auch aus dem Bereich Statistik, die umfangreiche Auswertungen erlauben. Der TWIST-Report bietet zusätzlich Mehrfachsortierung und zwei feldabhängige Gruppenbildungen.
Phoenix 3.5
Auch Phoenix, der Ästhet unter den Kandidaten, lag uns in einer überarbeiteten Version (3.5) vor. So verschwand jetzt das letzte Relikt aus dem schlichten GEM-Zeitalter. Die schnöde Dateiauswahlbox, die bisher die Phoenix-Oberfläche verschandelte, mußte einem Windows-Like-Dateiselektor weichen. Dabei fiel sogar funktional etwas für den Anwender ab: denn die verschiedenen Dateitypen lassen sich jetzt über ein Pop-Up-Menü direkt mit der Maus selektieren.
Auf vielfachen Wunsch hin wurde jetzt eine Volltextsuche integriert, mit deren Hilfe man mal schnell über alle Felder hinweg nach einem Begriff suchen kann. Beschleunigt wird dieser Vorgang außerdem dadurch, daß lediglich immer nur der nächste Datensatz gesucht und angezeigt wird, und nicht wie bei den beiden anderen Datenbanken, die jeweils ein neues Tabellenfenster öffnen mit jenen Datensätzen, die dem Suchkriterium entsprechen. Nichtsdesdotrotz steht auch einer solchen Suche via Eingabe eines SQL-Select-Befehls bzw. mausgesteuerten Zusammenbaus eines Select Befehls nur der Umstand im Weg. daß hierzu erst ein Prozeß mit Prozeßnamen eingerichtet werden muß. Apropos Suchen: Die Suche anhand eines Beispiels in der Eingabemaske (QBE -"Query by Example") unterstützen alle drei Datenbanken.
Die Auswirkungen des SQL-Unterbaus von Phoenix begleiten den Anwender durch das ganze Programm, mit all den positiven wie negativen Begleiterscheinungen. So muß die Multi-User/Multi-Tasking-Unterstützung mit einer gemächlicheren Ausführungszeit bezahlt werden. Dafür können aber schon unter dem Single-Task-TOS die Prozesse wie Suchen oder Rechnen im Hintergrund laufen. Während das Bearbeiten einzelner Datensätze in der Eingabemaske auch bei einem im Hintergrund laufenden Prozeß noch sinnvoll ist, erwies sich das Ablegen mehrerer Prozesse im Hintergrund als quälend langsam, da hier der Phoenix-interne Cache zuviel an Wirkung verliert. Der für den flüssigen Multitasking-Betrieb notwendige Tabellen-Cursor und das damit verbundene Record-Locking (Sperren) verbieten das Selektieren von mehr Datensätzen, als zurZeit im Tabellenfenster sichtbar sind, so daß die Funktion "Markiere alles" lediglich die sichtbaren Datensätze markieren kann. Wie SQL-Datenbanken auf anderen Betriebssystemen zeigen, könnte Phoenix mit einem Query-Optimizer in Sachen Geschwindigkeit noch deutlich zulegen. Bezüglich grafischer Unterstützung bei der Erstellung des Datenbankdesigns hat Phoenix den Idealzustand schon erreicht. Auf einen Blick erkennt auch der Datenbankneuling, was Sache ist. Gleiches läßt sich leider nicht von der Zuweisung der selbstgeschriebenen Rechnungen oder Batches sagen. Die Hauptschuld liegt an der Zweiteilung des Systems in den Designer, verantwortlich für das Tabellen- und Maskendesign, und den Manager, verantwortlich für die Datenverwaltung und die Programmierung der Rechnungen, Reports und Batches. Möchte man zum Beispiel einen Funktionsknopf in der Eingabemaske mit einer Rechnung verbinden und hat den Namen der gerade zuvor erstellten Rechnung wiedervergessen, gelangt man nur über den umständlichen Weg zurück zum Manager an den ersehnten Rechnungsnamen. Und das Spiel kann dann von vorne beginnen.
Entschädigt wird man dafür aber mit einer Programmiersprache (an Pascal angelehnt), die keine Wünsche offen läßt.
Fazit
Bei allen drei Programmen handelt es sich zwar um Datenbanksysteme, doch sind deren Konzepte derart verschieden, daß die entscheidende Frage nicht die nach dem besseren System ist, sondern die nach dem Einsatzgebiet. Für den Hobbybereich mit schmalem Geldbeutel und sich abzeichnendem kleinen Datenbestand bietet sich 1st-Base an. Für den, der umfangreichere Daten, evtl, auch mit Relationen, verwalten will, stellt sich die Wahl zwischen TWIST und Phoenix. Die Vorteile von TWIST sind hierbei die schnelle Verarbeitungszeiten, das schnelle und flexibles Redesign der Datensätze und die umfangreichen Relationsmöglichkeiten mit Verbundmasken. Phoenix hingegen glänzt mit seiner Programmierbarkeit und der Möglichkeit, eventuell sogar in einer Multi-Tasking/-User-Umgebung in einem Netz eingebunden zu werden.
| 1st-Base 2.0 | TWIST II | Phoenix 3.5 | |
|---|---|---|---|
| Import 1 | 00:21 | 01:35 | 11:13 |
| Import 2 | (1) | 02:08 | 15:00 |
| Volltextsuche | 00:08(1) | 00:36 | 04:13 (2) |
| Suche Text | 00:06(1) | <00:01 | <00:01 |
| Suche Wert | 00:05(1) | 00:01 | 00:01 |
| Löschen | -12:00 (1) | 00:10+02:36 | 02:26+26:03 (3) |
| Rechnen | 02:15(1) | 02:44 | 09:22 |
| Dateigröße | 2440 KB (1) | 4413 KB (4) | 7172 KB (4) |
(1) 1st-Base konnte den Datenumfang nicht mehr bewältigen, da nur ca. 2,2 MB RAM zur Verfügung standen. Die zweite Datei konnte daher nicht mehr importiert werden. Alle Ergebnisse beziehen sich also auf die halbe Datensatzanzahl und wurden hochgerechnet
Phoenix wäre bei einem Datenumfang, den 1st-Base gerade noch verwalten kann, mindestens doppelt so schnell: TWIST wäre etwa 3-5mal so schnell, da bei einer solchen Dateigröße der Lese-Cache von TWIST benutzt werden kann.
(2) Eine Auflistung aller gefundenen Datensätze war nur über den Umweg der Feldsuche möglich Die Volltextsuche bei Phoenix beschränkt sich auf das Verfahren 'Suche Datensatz' und 'Suche nächsten Datensatz' (siehe auch Text).
(3) Da hier auch die Selektierung der zu löschenden Datensätze erheblich Zeit in Anspruch nahm gibt die erste Angabe den Zeitbedarf der Selektion wieder
(4) Die Dateigrößen beinhalten auch die Indizes
Testumgebung
Getestet wurde auf einem ATARI Falcon (ca. 2,2 MB freier Speicher) mit einer Quantum LPS-340-SCSI-Festplatte und installiertem »CACHE90.PRG«. Bei langsameren Platten nehmen die Zeiten stark zu, besonders bei Phoenix. Die Umgebung hat also starken Einfluß auf die Ergebnisse Alle Testkandidaten wurden auf optimale Geschwindigkeit konfiguriert Der Schreib-Cache bei Phoenix blieb allerdings ausgeschaltet Die Testdatenbank bestand aus 13 Feldern (Datum, Float, Integer, Text). Die maximale Größe eines Datensatzes betrug ca. 600 Bytes. Fünf Felder wurden, soweit möglich (siehe Testbericht), mit einem Index belegt Der Import wurde aus zweierlei Gründen in zwei Stufen durchgeführt. Zum einen mußte 1st-Base bei größeren Datenbestanden passen, und zum zweiten sollte bei den anderen Kandidaten auch das interne Caching, dessen Qualität sich erst bei größeren Datenbeständen zeigt, unter die Lupe genommen werden Bei 'Import 1' wurde eine 1,2 MB große Datei in die leere Datenbank importiert Mit 'Import 2' wurde dann dieser Bestand nochmals um eine 1,2 MB Datei angereichert (jeweils 4400 Sätze) Alle weiteren Benchmarks wurden dann anhand dieses Datenbestandes durchgeführt Gelöscht wurden 2240 Datensätze. Die Rechnung bestand aus dem Inkrementieren eines Zahlenfeldes aller Datensätze (8600).
Jürgen Lietzow