Gibt es einen kompatiblen Befehlssatz unterschiedlicher SQL-Versionen?

[Edzard Egberts]

Ich möchte über eine ODBC-Schnittstelle möglichst viele unterschiedliche
Datenbanken bearbeiten können, gibt es dafür einen allgemeingültigen
Ausschnitt des SQL-Befehlssatzes?

Diese Seite https://www.sqltutorial.org/sql-list-all-tables/ hat mich
gerade geschockt, muss man für einen grundlegenden Befehl wie "Tabellen
der Datenbank anzeigen" wirklich für MSSQL, Oracle, MySQL, SQLLite, etc.
jeweils einen unterschiedlichen Befehl absetzen? Es gibt doch so etwas
wie einen SQL-Standard, sind da so grundlegende Sachen wirklich nicht
allgemeingültig definiert? Falls ja, wo finde ich die allgemeingültigen
Sachen?

[Erich Klecka]

Am 28.09.21 um 13:11 schrieb Edzard Egberts:

> Diese Seite https://www.sqltutorial.org/sql-list-all-tables/ hat mich
> gerade geschockt, muss man für einen grundlegenden Befehl wie "Tabellen
> der Datenbank anzeigen" wirklich für MSSQL, Oracle, MySQL, SQLLite, etc.
> jeweils einen unterschiedlichen Befehl absetzen?

Ja

> Es gibt doch so etwas wie einen SQL-Standard, sind da so grundlegende Sachen wirklich nicht
> allgemeingültig definiert?

Nein


--
ciao e.
Der Pragmatiker entscheidet Fälle nicht nach Grundsätzen, sondern
grundsätzlich fallweise.
Man kennt mutige Kapitäne, es gibt alte Kapitäne, es finden sich aber
keine mutigen alten Kapitäne

[Peter J. Holzer]

On 2021-09-28 11:11, Edzard Egberts <ne...@edzeg.net> wrote:
> Ich möchte über eine ODBC-Schnittstelle möglichst viele unterschiedliche
> Datenbanken bearbeiten können, gibt es dafür einen allgemeingültigen
> Ausschnitt des SQL-Befehlssatzes?

Jein. Die Antwort lautet: Der Teil des SQL-Befehlssatzes, der in
möglichst vielen Datenbanken implementiert ist. Das hilft Dir aber nicht
weiter.

Du kannst nicht davon ausgehen, dass alles, was im Standard steht,
überall funktioniert. Keine Datenbank implementiert den kompletten
Standard (selbst die PostgreSQL-Leute, die recht stolz darauf sind, dass
sie sehr nahe am Standard sind, sagen bei manchen Features schlicht
"Nein, das machen wir nicht" oder "Nein, das machen wir anders"), und
umgekehrt gibt es einige Features, die sehr weit verbreitet sind und
nicht im Standard stehen.

Das ist einfach Erfahrung. Die macht man mit der Zeit, wenn man mit
mehreren Datenbanken arbeitet. Aber wenn eine bisher unbekannte
dazukommt, kommen auch neue Erfahrungen dazu.

Oder Du verwendest ein ORM oder einen SQL-Builder (in Python z.B.
SQLAlchemy), da haben andere Leute die Erfahrung schon gemacht.
Hat weitere Vorteile, aber auch Nachteile (insbesondere ist das wieder
eine andere Sprache, die man erst lernen muss, und es ist ein weiterer
Abstraktionslayer, der lecken kann (und meiner Erfahrung nach auch
wird)).

> Diese Seite https://www.sqltutorial.org/sql-list-all-tables/ hat mich
> gerade geschockt, muss man für einen grundlegenden Befehl wie "Tabellen
> der Datenbank anzeigen" wirklich für MSSQL, Oracle, MySQL, SQLLite, etc.
> jeweils einen unterschiedlichen Befehl absetzen?

Nein, aber die standardisierte Methode ist eher ein bisschen mühsam.
Daher (und auch weil es die meisten Datenbanken schon länger gibt als
den entsprechenden Abschnitt im Standard) hat jede Datenbank noch
"Abkürzungen".

Der Befehl heißt "SELECT" und man holt sich damit die Informationen aus
dem (einfallsreich benannten) information_schema. Also z.B. für die
Liste alle Tabellen:

select * from information_schema.tables;

Das geht ja noch, aber wenn Du Dir alle Informationen über eine
bestimmte Tabelle zusammensuchen willst (Spalten, Indexes, Foreign Key
Constraints, Check Constraints, ...) musst Du in einem halben Dutzend
verschiedener Tabellen nachschauen.

(Wobei man der Fairness halber dazusagen muss, dass das bei Oracle und
PostgreSQL auf SQL-Ebene auch mit den proprietären Methoden nicht anders
ist - DESC und \d sind Kommandos der SQL-Shell, keine SQL-Querys)

> Es gibt doch so etwas wie einen SQL-Standard, sind da so grundlegende
> Sachen wirklich nicht allgemeingültig definiert? Falls ja, wo finde
> ich die allgemeingültigen Sachen?

Im information_schema. Bzw. im Standard, denn jede Datenbank legt dort
auch Dinge ab, die nicht standardisiert sind, und wenn Du Dich darauf
verlässt, dass z.B. information_schema.tables eine Spalte create_time
enthält, nur weil es die in MySQL gibt, wirst Du bei PostgreSQL auf die
Nase fallen.

hp

[Edzard Egberts]

Am 17.10.21 um 12:11 schrieb Peter J. Holzer:

> On 2021-09-28 11:11, Edzard Egberts <ne...@edzeg.net> wrote:
>> Ich möchte über eine ODBC-Schnittstelle möglichst viele unterschiedliche
>> Datenbanken bearbeiten können, gibt es dafür einen allgemeingültigen
>> Ausschnitt des SQL-Befehlssatzes?
>
> Jein. Die Antwort lautet: Der Teil des SQL-Befehlssatzes, der in
> möglichst vielen Datenbanken implementiert ist. Das hilft Dir aber nicht
> weiter.

Na ja, ich weiß jetzt zumindest, dass SQL nicht meiner Vorstellung von
Programmiersprache entspricht. Das sind also alles einzelne Produkte,
die sich für diesen Themenbereich nie auf eine übergreifende Lösung
einigen konnten. Irgendwie schräg, damit rechnet man heutzutage doch
nicht mehr. Ich käme mir völlig bescheuert vor, wenn ich sagen würde,
ich programmiere "Microsoft Visual Studio C++" oder alternativ "g++",
statt einfach nur "C/C++", aber bei "TSQL" oder "MySQL" wäre das dann
wohl eine richtige Einschränkung. :o/

> Oder Du verwendest ein ORM oder einen SQL-Builder (in Python z.B.
> SQLAlchemy), da haben andere Leute die Erfahrung schon gemacht.

In meinem Fall wohl eher eine ODBC-API. Habe mir ein paar angesehen, bin
aber selber eigentlich schon weiter.

> Der Befehl heißt "SELECT" und man holt sich damit die Informationen aus
> dem (einfallsreich benannten) information_schema. Also z.B. für die
> Liste alle Tabellen:
>
> select * from information_schema.tables;

Das hilft mir weiter, dass dieses information_schema etwas
Allgemeingültiges ist, war mir nicht so klar, also mit
information_schema und den "normalen" SQL-Befehlen kommt man dann wohl
schon ziemlich weit. Wenn es um Details des information_schema geht,
lande ich allerdings auch immer wieder bei der Doku einer einzelnen
Datenbank. :o(

> Das geht ja noch, aber wenn Du Dir alle Informationen über eine
> bestimmte Tabelle zusammensuchen willst (Spalten, Indexes, Foreign Key
> Constraints, Check Constraints, ...) musst Du in einem halben Dutzend
> verschiedener Tabellen nachschauen.

Na ja, ist eben Arbeit. Wenn man einmal etwas mehr, statt für jede DB
etwas mehr oder weniger schreiben muss, ist das für mich in Ordnung.

[Axel Schwenke]

On 18.10.2021 13:14, Edzard Egberts wrote:
> Am 17.10.21 um 12:11 schrieb Peter J. Holzer:
>> On 2021-09-28 11:11, Edzard Egberts <ne...@edzeg.net> wrote:
>>> Ich möchte über eine ODBC-Schnittstelle möglichst viele unterschiedliche
>>> Datenbanken bearbeiten können, gibt es dafür einen allgemeingültigen
>>> Ausschnitt des SQL-Befehlssatzes?
>>
>> Jein. Die Antwort lautet: Der Teil des SQL-Befehlssatzes, der in
>> möglichst vielen Datenbanken implementiert ist.
>

> Na ja, ich weiß jetzt zumindest, dass SQL nicht meiner Vorstellung von
> Programmiersprache entspricht. Das sind also alles einzelne Produkte, die
> sich für diesen Themenbereich nie auf eine übergreifende Lösung einigen
> konnten. Irgendwie schräg, damit rechnet man heutzutage doch nicht mehr.

Na ja. Das Beispiel "liste mir alle Tabellen auf" war auch schlecht gewählt.
In der Praxis braucht eine *Anwendung* das nicht. Genauso wenig, wie eine
Aufzählung aller Variablen in einem Programm.

> Ich
> käme mir völlig bescheuert vor, wenn ich sagen würde, ich programmiere
> "Microsoft Visual Studio C++" oder alternativ "g++"

Sobald du Nicht-Standard Funktionen aus der jeweiligen "Standard" (hehe)
Library benutzt, machst du genau das. Z.B. ist POSIX in Windows nur sehr
lückenhaft implementiert. Dafür hat Windows (aka Visual C++) wieder
Sonderlocken, die du nur da findest.

> In meinem Fall wohl eher eine ODBC-API.

Bloß nicht. ODBC ist so ziemlich das übelste, was man verwenden kann. Nimm
einfach das Abstraktionslayer, das mit deiner Programmiersprache kommt. Java
finde ich persönlich zwar voll daneben, aber JDBC ist ok.

>> select * from information_schema.tables;
>
> Das hilft mir weiter, dass dieses information_schema etwas Allgemeingültiges
> ist, war mir nicht so klar

Ist es nicht. Auch I_S unterliegt den "natürlichen" Schwankungen der
Kompatibilität. Schau dir einfach mal die Unterschiede von I_S in
verschiedenen MySQL-Versionen an. Wenn du Pech hast, bist du auf einem alten
MySQL unterwegs, da gibt es das gar nicht ...

[Edzard Egberts]

Am 18.10.21 um 16:58 schrieb Axel Schwenke:

> On 18.10.2021 13:14, Edzard Egberts wrote:
>> Am 17.10.21 um 12:11 schrieb Peter J. Holzer:
>>> On 2021-09-28 11:11, Edzard Egberts <ne...@edzeg.net> wrote:
>>>> Ich möchte über eine ODBC-Schnittstelle möglichst viele unterschiedliche
>>>> Datenbanken bearbeiten können, gibt es dafür einen allgemeingültigen
>>>> Ausschnitt des SQL-Befehlssatzes?
>>>
>>> Jein. Die Antwort lautet: Der Teil des SQL-Befehlssatzes, der in
>>> möglichst vielen Datenbanken implementiert ist.

Letztendlich habe ich den Wald vor lauter Bäumen nicht gesehen - die
Sonderinformationen wie "alle Tabellen auflisten", "alle Datenbanken
auflisten" usw. lassen sich über die ODBC-API abfragen und das
funktioniert dann auch mit "Datenbanken" wie MS-Excel.

>>> Bloß nicht. ODBC ist so ziemlich das übelste, was man verwenden
>>> kann.

Hat schon etwas gedauert, bis ich da durchgestiegen bin, aber jetzt
funktioniert das mit C++ ganz gut.