ADD Sinn und Zweck bzw. Einsatzgebiet(e)

[Manfred]

Hi,

ich habe hier mal einen Thread eröffnet, wozu das Data Dictionary benutzt oder eingesetzt werden könnte/sollte. Mal schauen, was dabei so alles entsteht.

Also, jeder kann, keiner muß hier was zu schreiben.

[Tom]

Das ADD (Advantage Data Dictionary) macht aus der uns aus dem "klassischen" Xbase-Segment bekannten Sammlung von Tabellen tatsächlich eine Datenbank. Wenn wir nicht mit einem solchen oder ähnlichen Werkzeugen arbeiten, besteht aus unserer Sicht eine Datenbank schlicht aus einer Ansammlung von Dateien, die u.a. zufällig Tabellen oder Indexe sind - oder irgendwas sonst. Ähnlich verhalten sich fast alle Datenbankserver und vor allem die SQL-Server, die sogar einzelne Tabellen und Indexe verstecken. In monolithischen Datenbanken (dazu gehört auch Access) gibt es keine physikalischen Tabellen; sie befinden sich wie die Indexe und Metainformationen in einer Datei, die die komplette Datenbank enthält, u. U. sogar Abfragen und Auswertungen.

Eigentlich ist das ADD aber "nur" ein Tool, das es erlaubt, Tabellen anzulegen, zu pflegen, zu indexieren, ihre Indexe zu überarbeiten, Daten zu importieren usw. Wenn die Anwendung selbst die Verbindung zum ADS aufbaut, ohne zum ADD zu konnektieren, bleibt das ADD auch ein solches Tool. Wenn die Verbindung über das ADD erfolgt, was auch im Kontext der ADSDBE möglich ist, kann es sogar so sein, dass die Anwendung überhaupt nicht mehr weiß, wo sich die Tabellen und Indexe physisch befinden. Der ADS verhält sich dann ähnlich wie ein MySQL- oder Microsoft-SQL-Server: Die Tabellen sind nur noch als Bestandteil der Datenbank verwendbar, aber nicht mehr ohne diese Datenbank(verbindung). Im Gegensatz zu den SQL-Servern gibt es die Tabellen und Indexe trotzdem weiterhin, nur werden sie vom ADD verwaltet. Wenn man den ADD einsetzt, aber ihn nicht für die Verbindung verwendet, kann es einem passieren, dass ADD und Anwendung unterschiedliche Zustände herstellen. Die Anwendung kann Tabellen strukturell verändern, ohne dass der ADD das mitgeteilt bekommt, woraufhin er möglicherweise wieder eine Restaurierung vornimmt, wenn man ihn aufruft. Der ADS erlaubt zudem die Umgehung der Rechtestrukturen. Eine Datenbank kann aus einer Anwendung heraus verwendet werden, obwohl der Benutzer, der mit der Anwendung arbeitet, auf Betriebssystemebene nicht das Recht hätte, auf die Tabellen zuzugreifen. Da er aber eine Verbindung über der ADS verwendet, kann er in diesem Fall unbemerkt die Rechte erben, die der ADS hat. Das kann man mit dem ADD noch etwas weiter treiben, wenn man möchte.

Sehr wichtig ist nach meinem Dafürhalten, dass die Anwendung eine andere Sicht auf die Daten hat, wenn mit dem ADD und/oder von der ADS geerbten Rechten gearbeitet wird. Mit dem ADD kann es so sein, dass überhaupt keine Low-Level-Operationen (von File() bis FErase()) mehr möglich sind, weil die Anwendung nicht einmal mehr weiß, wo die Daten eigentlich sind. Die Anwendung muss sich also darauf verlassen können, dass der ADD korrekt konfiguriert ist. Wenn Tabellen gelöscht werden sollen, müssen sie von der Anwendung aus dem ADD geschmissen, wenn sie erzeugt werden, dem ADD hinzugefügt werden - etwa temporäre Tabellen oder ähnliches.

Es gibt meiner Kenntnis nach Servicefunktionen, die die ACE (Advantage Client Engine, ausgeliefert als ACE32.DLL) enthält, und die genutzt werden müssten, um ein Dictionary zu pflegen. Ich würde behaupten, dass das essentiell wäre, wenn man eine Anwendung die Datenbankverbindung über das ADD herstellen lässt. Auf sämtliche Operationen, die auf Dateiebene Tabellen und Indexe manipulieren, müsste man verzichten. Oder?