Je nachdem
Du hast in der MS Welt in der Regel ein paar historische gewachsene Geschichten
a) Die Client Library welche mit der Datenbank kommuniziert. libmysql.dll
a1) zu der gibt es ein Header File bspw. für C Programmierung
a2) jede Datenbank hat eine eigene Bibliothek/Library für den Zugriff
a3) jeder nennt die Funktionen für den Zugriff auf eine Datenbank anders und sie verhalten sie anders
b) Als Datenbanken aufkamen hatte jeder Schuppen nur eine. Mit der Zeit wollten die Kunden oder Werkzeughersteller aber nicht auf dieser Ebene eine Abhängigkeit vom Hersteller einhandeln. Deswegen wurden Standards beschlossen. Einer davon wäre bspw.
ODBC realisiert über einen Treiber
b1) CLANG bspw. wäre ein Treiber für verschiedene C/C++ Compiler.
b2) MS hatte keine Datenbank und war als 'Werkzeughersteller' an Normierung interessiert
c) Ein Treiber harmonisiert weitestgehend die unterschiedlichen Funktionsname und das Verhalten seiner Funktionen in Richtung des Programmierwerkzeugs
c1)
ODBC, OLEDB, DBX,
BDE (Borland Database Engine aus DOS Zeiten).
c2) Ein Treiber nutzt an sich die Funktionen der Client Library wie er will
Ebene Progammierumgebung und Komponenten
d) Microsoft hatte 2 Komponentenarchitekturen DAO und RDO (Remotekomummikation zu einer
DB ohne (komplexen) Treiber am Client) die später durch
ADO wurden abgelöst. Die Sicht Table,
Query, Stored Procedures als Komponenten stammt eher aus der DA Sicht. Diese Sicht ist aber weder berühmt noch abwegig.
d1) Du empfängst immer Ergebnisse einer Abfrage. Es gibt auch Bibliotheken in C/C++ die solche Ergebnisse als Stream behandeln.
e) Borland/Embarcadero hatte ihre Borland Database Engine und auch DBExpress. Aus
DB Express stammt die TSQLQuery.
f) MS ging dann her und hat in
ADO (
ActiveX Data Object) das Konzept der Tables, Queries usw. harmonisiert und als ein Ergebnis der Harmonisierung ging das 'Command' hervor. ADOCommand,
ADO.net Command. So ein ähnliches Konzept findet sich auch in FireDAC wieder. *)
g) Die Harmonisierung der verschiedenen Konstrukte (
Query, Table, usw...) bei Borland erfolgte über den TDataSet und bei MS war es der Command.
g1) Eine
Query im U.S. Sprachgebrauch ist eigentlich eine parametrierbare View. Wenige Datenbanken kann zu Beginn Views und manche wie X-Base Datenbanken gar nicht. Ein Zeit nahm der Table diese Rolle ein und die
Query war eher fokussiert auf DML Statements. Kurz danach gesellte sich wieder der ResultSet (Abfrageergebnis) zur
Query hinzu.
*) Eigentlich kümmert sich ein Command um das
SQL Statement (
Query, Table, Stored Procedures basieren auf Commands und auch andere Komponenten). Ein
SQL Statement kennt Ergebnisfelder und Bind Variablen in erste Linie.
Im Delphi selbst gibt es eine zentrale Komponente die eigentlich alles macht und diese ist die *Connection*.
(*
Die
Query ist, wie in den Filmen aus den 80ern mit den blonden Business Ladies mit den großen Brillen welche gestresst in Bürotürmen vor einem Terminal saßen und tonnenweise Endlospapier am Schreibtisch liegen hatten, die Businesssicht bezogen auf einen Datenbestand in Beziehung zu einem einen Arbeitsplatz, ein Ergebnis angezeigt auf einem Terminal (IBM Host) welche auf einem Report wurde gedruckt. QMF (
Query Management Facility) erinnert noch dran. Damals war die
DB noch eine logische schicht gleichstrukturierte Dateien. Deswegen sind die Queries im
SQL Server auch als eine Businesssicht vorhanden. Eine
Query ist an sich kein
SQL-Statement, eine
Query kann auf einem solchen basieren.
QMF in der Delphi Welt wäre 'Editing Data in FDMemTable at Designtime'.
*)
Eine Connection sofern die Komponenten (d) bis g) )nicht direkt auf einer Client Library aufsetzt bemüht einen Treiber. Das kann sein ein
ODBC Treiber, ein OLEDB Treiber oder (OLDEB über
ODBC), ein DBX (
DB Express) Treiber. Heute macht eher die Connection die Arbeit und mithilfe einer
Query beschreitet der Entwickler einen mehr oder minder komfortablen einheitlich Weg eine Abfrage zusammenzustöpseln.
Die Queries der Borland Welt halten zwecks Navigierbarkeit das Ergebnis der Abfragen in 'ihrem' Puffer. Pures
ODBC macht das nicht.
Normalerweise wird beim Parsen eines
SQL Statements nach Bind Variables gesucht ':' vor dem Namen.
a) Ein Field ist ein Wert (Zelle) in einer Zeile eines Abfrageergebnisses.
b) Eine FieldDefinition ist ähnlich der Definition einer Column in einer
DB (vereinfacht gesagt). Eigentlich ein Beschreibung von beliebigen Bytes im Ergebnispuffer. Man kan vereinfacht sagen, eine
Query gibt eine neue Tabellenstruktur mit Zeilen zurück (Dynamisch erzeugter Typ) vs. dem Statischen Datenbanktabelle.
c) Param ist eine Bind Variable
Die Defintion eines Parameters einer Abfrage und einer Felddefintion beschreibt bestenfalls mal in erster Linie die Interpretation des übergebenen Werts (sagen wir mal so).
Du brauchst die Connection damit überhaupt irgendein Teil der Software die Abfragen wegschickt, die Ergebnisse in Empfang nimmt, die Transaktion handelt (
DB Connection hat Transaction) usw...
TSQLConnection wäre dann die Verbindung zur Datenbank welche DBX (
DB Express) Treiber bemüht, die greifen ihrerseits auf die DBClientLibrary (bspw. libmysql.dll) zu . DBX hat noch dazu Treiber die man stacken kann (vergiss das für den Moment).
Den Rest haben dir die das Forum Bewohnenden schon geschrieben.