On 2023-06-17 22:15, Maik Koenig <
usene...@maikkoenig.de> wrote:
> Am 17.06.2023 um 23:49 schrieb Tim Landscheidt:
>> Das Stichwort wäre „JOIN“. In diesem Beispiel müsste (unge-
>> testet):
>>
>> | SELECT Tabelle1.id,
>> | Tabelle2.text
>> | FROM Tabelle1
>> | JOIN Tabelle2 ON Tabelle1.foo = Tabelle2.id;
>>
>> das Gewünschte leisten.
>
> Wenn ich das richtig verstehe ist das eine Abfrage welche diese
> Verbindung für das jeweils gelieferte Ergebnis herstellt, keine
> Einstellung in der Datenbank bzw der Spalte selbst. Demnach muss man das
> also immer wieder genau so machen, bei jeder Abfrage.
Richtig. Das ist die Idee hinter einer relationalen Datenbank.
Man speichert die Daten in "Relationen" (= Tabellen) weitgehend
unabhängig von den tatsächlichen Abfragen (Siehe Normalformen). Das, was
man dann tatsächlich braucht, kann man in der Abfrage formulieren, ohne
die Datenbank speziell auf die Abfrage optimieren zu müssen.
(Das war damals durchaus eine Innovation. Davor musste man sich sehr
genau überlegen, welche Abfragen man haben wird, und die Daten
entsprechend speichern.)
> Einen Automatismus der bei "normalen" SELECT-Abfragen schon in der
> Datenbank selbst greift gibts nicht?
Es gibt Views. Du kannst einen View definieren:
create view v1 as
select
tabelle1.id,
tabelle2.text
from tabelle1
join tabelle2 on tabelle1.foo =
tabelle2.id;
Und dann den View wie eine Tabelle verwenden, also z.B.
select * from v1 where text = 'Bielefeld';
Das ist vermutlich am nähesten an dem, was Du dir vorstellst. Der View
wird zum Abfragezeitpunkt ausgewertet, man bekommt also immer die
aktuellen Daten. Das hat aber auch den Nachteil, dass man leicht sehr
komplizierte Views bauen kann und sich dann wundert wieso ein einfaches
Select so langsam ist.
hp