Zu Zeiten von BTRIEVE (Record Server) hat man die binäre Repräsentation eines Record in eine Datenbank abgelegt. Man hat an sich noch mitgegeben wie Character mit Code Pages zu interpretieren waren (Sortierung usw...).
Relationale
SQL Datenbanken sind von der
API her konzipiert für 4GL.
SQL war zu Beginn eine Art Export Facility. Im Prinzip ein klassisches Provisorium. Und wie üblich in der IT hat man drüber gebaut. Es war für Unternehmen eine Befreiung, sie waren nicht mehr vom File Format von Anwendungen und programmierter Zugriffsprogrammen abhängig. Ich kenne noch ITs die haben Listen programmiert in C. So machen IT Leiter nicht heruntergestiegen und auch nicht Produkthersteller. Sichert das Businessmodell des einzelnen Hersteller oder Orgeinheit... Warum glaubst du gibt es soviele Fileformate. Die IT's konnten mit relationalen Datenbanken ihre eigenen Daten auslesen, aufbereiten usw...
Es gibt an sich ein paar Standards. Dann gab es mal
ANSI SQL. Diese Standards wurden implementiert und gleichzeitig haben die Datenbankhersteller auch aus durchaus ehrbaren Motiven Programmiersprachen eingebaut in die DBs... damit haben sie den Kunden anders eingefangen. Die sind geliefert in der Praxis. Es gäbe einen Prozeduralen Stand für DBs - der kam zu spät und kann nicht viel. Die Mimer hat den relativ exakt implementiert. - Alles nur
DB.
Jetzt hat man 2 Arten von Zugriff.
Query - Abfrage und im Prinzip das Ausführen einer Prozedur und Übernahme des Ergebnisses das wiederum eine oder mehrere Tabellenstrukturen sein können. Etwas frei formuliert - explizite und implizite Cursor. Ist das verpackt in einer zumeist in C implementierten library dann spricht man von einem Treiber.
ODBC ist ein gelungener Versuch ein normierten Datenbanktreiber zumindest aus Sicht der Anwendung respektive des Programmieres anzubieten. Einige Unterschiede verbleiben, ob des gemeinsamen Nenners.
BDE und
DB auf Treiber Ebene sind ähnlich gelagert.
DBX wurde von Borland nicht weiterentwickelt. Die Treiber selbst waren an sich gut und das Konzept ansprechend. Die Komponentenseite war nichts ganz sauber. Nach einigen Versuchen im Guten Borland davon zu überzeugen die Komponentenseite zu verbessern hat dann ursprünglich ein Schweizer Unternehmen ihre OffShore (Dmitry Arefiev damals der Treiber hinter dem Ganzen) AnyDAC heute FireDAC geschrieben. Am Anfang wollte man Oracle direkt (NCOCI Ablöse),
ODBC (Alternativ OLEDB, das wurde aber verworfen) und DBX unterstützen. Das hat so lala funktioniert, aber die Lösung war eben dann der Umweg über eine eigene
SQL Ebene die auf
SQL umgesetzt wird, das die Datenbank versteht. Diese normierende Schicht hat auch UNIDAC. Die Komponentenebne (TDataset Compatibility) frisst 40% der Speed.
n-tier. Heißt nichts anderes als die Anzahl von RPC Indirektionen beginnend mit 1. pro Indirektion kommt eine dazu. Der Client Server Zugang (zumeist der Client spricht dem Server über eine eigens Protokoll. Das geht von einfach
DEC RPC, IBM CPI-C in gewisser weise, SAP RPC, SAP
GUI Protokoll, OCI,
SQL PLUS Protokoll usw.. Das sind die 2 Tier Ansätze. Die haben alle eines gemeinsam. Der Client bekommt einen Bytestream und muss den mit bekannter Metainformation (Datensatzaufbau, Characterset usw...) interpretieren sodass mein Funktionsaufruf aus der 3GL Sprache (C, Pascal usw...) etwas verarbeitbares rauskommt.
Im Prinzip wurden dann Elemente eingeführt die RPCs in Empfang nehmen (Proxies, Datasnap, ... usw...). Die Apptier war am Anfang eher eine Pooling Ebene die einfach die
DB Sessions sollte entlasten. Klassiker ist (MTS von Microsoft). Der
SQL hat in 60 keine 10 User geschafft ... Das war schon ein Schitt in Richtung 3Tier. Klassische 3 Tier ist Java und .net Remoting. Davon losgelöst hat sich CORBA als objektorientierter Zugang stark lastig im Sinne von OO rausgebildet eben noch begrenzt durch die Möglichkeiten des RPC. Das war eine verbesserter RPC zu Beginn. Ein anderer Ansatz sind Appserver - BEA (Objekt Proxies). Java hat damals einfach gewonnen da die Serialisierung weitaus einfach ging als in C/C++ mal ganz zu schweigen davon, dass man mit CORBA Librares RECORDS hat dynamisch zusammengebastelt. Der
DB Access war so langsam dass man hergegangen ist und in der Not Java Objekt Repräsentationen hat gepoolt und das hat in der damaligen Zeit die Smalltalk und OO Typen nachdem sie mit OO Database grandios gescheitert waren sehr gut ins Konzept gepasst (ORM und Persistenzcontainer in die Java Appserver). Die Synthese von Dingen die nie funktioniert haben.
Die 3 Tier wurde eingeführt damit man eben noch eine zusätzliche Protokollabstraktion reinbekommt. An sich wäre es so dass die Objekte auf der Apptier genauso lebten und am
GUI nur angezeigt werden. Egal wie man technisch Realisiert.
Web ist kein reiner 3 Tier in klassichen Definition. Ein HTTP Request ist eine andere Abstraktionsebene als der traditionelle RPC. In dem Sinne ist HTTP ein alternatives Protokoll zum RPC aber doch ein wenig mehr. Protokolle sind beide.
Jetzt kommt die Gretchenfrage. Erzeugst du dir ein Objektlayer. Ich generiere mir auch einen. Eines darf man nicht vergessen. Eine Select Statement erzeugt zur Laufzeit Typen ... der Typ im Programm ist statischen (Impedance Missmatch). An sich für eine Applikationsperistenz Objekte ja und im schlimmsten Fall Collections aufbauen. Wenn das Ziel der Datenbank in kombinierbare Informationsbasis ist, dann Vorsicht. Objekte sind aus der Sicht zugreifenden Applikation eine Wahrheit die gegen das Informationsmodell beim DML geprüft wird oder alternativ in der TDataset Welt...
Nun, da ich ja leider (noch) keine Ahnung von der klassischen Datenbankprogrammierung habe (also die Sachen, die Delphi so anbietet), meine Frage, ob es hierzu entweder Literatur oder Demo-Beispiele gibt, wo einmal demonstriert wird, wie man das von Dir beschriebene Modell implementiert?