Alternative Datenspeicherung

Alternativen zur DBF-Datei

Welche Gründe sprechen dafür, auf die klassischen Speicherformen DBF/NTX bzw. DBF/CDX zu verzichten?

Das Dateikonzept stammt aus der Zeit der Einzelplatz-PCs, in denen Netzwerke teure und hochkomplexe Systeme waren. Zudem war DOS, unter dem dBase/Clipper das Licht der Welt erblickte, definitionsgemäss ein single user/single task Betriebssystem (wovon auch die speicherresidenten Programme wie SideKick nichts änderten).

Dementsprechend sind die Dateizugriffe auch auf eine Einzelplatzanwendung ausgerichtet, und Netzwerkmechanismen sind erst später hinzugekommen und erwecken auch heute noch den Eindruck, dass ihr Konzept nicht richtig durchdacht war.

Die Datenverwaltung unter native Clipper/xBase++ entspricht distributed computing: jeder Rechner operiert für sich alleine, und Änderungen in Datendateien (DBF) und Indexen (NTX/CDX) müssen vom einzelnen Rechner auf einer zentralen Resource (meist ein Server, oder ein freigegebenes Laufwerk auf einem der Rechner im Netzwerk) ausgeführt und mit den anderen Rechnern koordiniert werden.

Gerade wenn viele Arbeitsstationen viele Datenoperationen durchführen (besonders Änderungen in den Index-Dateien) ist die Gefahr von korrupten Index-Dateien sehr hoch. Unsauber programmierte Sperren führen darüber hinaus zu sehr schleppend laufenden Programmen (schlechter Programmierstil wird durch einen SQL-Server aber auch nicht besser).

Parallel wurden Systeme entwickelt, die eine zentrale Datenverwaltung und Zugriff über Netzwerke realisierten. Stichwort hier ist SQL (Structured Query Language).

Hier gibt es einen zentralen Server, der von den Client-Rechnern Anfragen (Queries) entgegennimmt und Daten liefert, schreibt und ändert. Die Hoheit über die Änderung der Daten liegt nun nicht mehr bei zahlreichen Client-Programmen, sondern bei einem zentralen Dienst.

Heutige SQL-Server sind in der Lage, sehr hohes Datenaufkommen "mit links" abzuwickeln und bieten sich als Daten-Backend geradezu an.

Hier gibt es zwei verschiedene Wege, die wir zuerst aus der Sicht der Kommunikation betrachten:

Datenkommunikation zwischen Applikation und Datenprovider

ODBC

Open Database Connectivity (auch als MDAC (Microsoft Data Access) bekannt) dient als Zwischenschicht dazu, alles wie einen SQL-Server erscheinen zu lassen, theoretisch sogar eine Textdatei. Der ODBC-Treiber für eine Datenquelle nimmt SQL-Anweisungen entgegen und übersetzt sie in eine Form, die vom Datenprovider verstanden wird, und liefert das Ergebnis dann an die Anwendung zurück.

Derzeit gibt es zwei Produkte, über die ein Xbase++ Programm mit ODBC-Datenquellen kommunizieren kann:

SQLExpress

SQLExpress von Boris Borzic stellt eine DLL-basierte Schnittstelle zur Verfügung, über die ein Xbase++ Programm mit einer beliebigen ODBC-Datenquelle zusammenarbeiten kann.

ODBCDBE

Als kostenpflichtiges Zusatzprodukt in der Professional Subscription bietet ODBCDBE die Möglichkeit, den Zugriff auf ODBC-Datenquellen über eine DBE in ein Xbase++ Programm einzubinden.

API-Zugriff auf Datenserver

ADS

Die bekannteste Schnittstelle dürfte der Zugriff auf einen ADS Server sein, denn hier hat Xbase++ die entsprechende Schnittstelle bereits im Gepäck.

API-Wrapper

Jeder SQL-Server, der etwas auf Konnektivität gibt, verfügt über eine Sammlung von APIs, mit denen die Kommunikation zwischen externen Programmen und dem Server durchgeführt werden kann.

Als Beispiel sei hier auf den MySQL-Wrapper und den PostGreSQL-Wrapper von Hector Peroza, sowie den SQLite-Wrapper von Pablo Botella verwiesen.