SubSelect

[Kampfgummibaerlie]

Ich frage mich, wieso das so Umfangreich unterrichtet wird, war heute bei einer höheren Schulstufe als Zuhörer und die haben (alle bereits mit Matura ausgestattet) derzeit bei Datenbanken das Thema "Sub-Selects".

Mir wäre bisher nie aufgefallen, dass ich sonderlich viele SubSelects (Datenbank Mimoso) einsetzen musste. Ich verwende einfach auf der Homepage, wo ich möglicherweise den Namen anzeige, die id als "Wert".

Was ich mir vorstellen kann wäre, dass das bei Triggern evtl. nötig sein könnte, Beispiel:
Kunde löscht Account
Offene Bestellungen werden mitgelöscht

einfach einen üblichen Trigger mit folgendem Funktions-Body:

delete from bestellungen where kunde = (select id from kunde where id = old.id)

Beispiel probiert (Hier Code):

create table kunde(id integer primary key);
create table bestellung(kunde integer references kunde(id), produkt integer not null);

create function del() returns trigger as $$
begin
delete from bestellung where kunde = (select id from kunde where id = old.id);
return old;
end; 
$$ language plpgsql;

create trigger del before delete on kunde for each row execute procedure del();

insert into kunde values (1);
insert into bestellung values (1, 1);
delete from kunde;

Dann sollte in Bestellung auch nichts mehr sein.
Probe:

select * from bestellung;

Result:

-

wird das Thema SubSelect relevanter, wenn ich mich mit Procedures beschäftige?

 

[Kampfgummibaerlie]

Ich wage es, mich an meinen Ursprung zu erinnern.

Apache OpenOffice Base !

Es gibt viele Oberflächen, bei welchen das einen Sinn hat.

 

[castorp]

Das Beispiel ist natürlich etwas schlecht gewählt, weil man dieses Verhalten besser mit einem Foreign Key abbildet der mit ON DELETE CASCADE definiert wird.

Sub-Selects braucht man z.B. für eine EXISTS Bedingung und typischerweise wenn man keine Joins zum Testen der Existenz von Tabellen verwenden möchte. Für die Abfrage "Gib mir alle Kunden die bereits mindestens eine Bestellung getätigt haben"

select k.*
from kunde k
where id in (select kunden_id from bestellung);

(Alternativ kann man das auch mit einem EXIST schreiben, was manchmal schneller ist)

Mit einem Join muss man dann entweder die Duplikate entfernen von Kunden die mehr als eine Bestellung haben, oder man muss mit einem outer join arbeiten und die "ohne Bestellung" wieder entfernen:

select distinct k.*
from kunde k
  join bestellung b on b.kunden_id = k.id

Das klappt aber nicht, wenn in der Tabelle kunde Spalten drin sind bei denen man kein DISTINCT machen kann (bytea, json), also muss ein
outer join her:

select k.*
from kunde k
  left join bestellung b on b.kunden_id = k.id
where b.produkt is null

In beiden Fällen werden wesentlich mehr Datensätze verarbeitet als man tatsächlich benötigt.

Es gibt einige die lieber den outer join verwenden als ein IN oder EXISTS, ich persönlich finde das nicht so schön.

 

[ukulele]

Also in der Schule lernt man Grundlagen und, soweit ich das beurteilen kann, haben die nicht viel mit der Praxis oder dem realen Leben zu tun. Ich würde das also nicht überinterpretieren. In Mathe befasst du dich ja auch nicht mit Einkommensteuer, obwohl du das sicher besser brauchen könntest als Parabeln oder Ableitungen.

Vermutlich werden die z.B. eine laufende Summe mit einem Subselect abbilden um zu zeigen, wie es funktioniert. In der Praxis kann jetzt fast jede DB Window-Functions.

Trigger sind sicherlich nicht die Zielanwendung. Zumal Softwareentwickler in der Praxis viele Funktionen in Datenbanken gar nicht nutzen sondern das auf Application Ebene abbilden. Ich habe jedenfalls noch keinen Trigger erlebt, der nicht von mir eingebaut wurde.

Das mit EXISTS vs JOIN ist ein spannendes Thema. EXISTS kann schneller sein weil es z.B. im Gegensatz zu einem join die Spalten nicht als Teil der Ausgabe laden kann und somit gar nicht die ganze Tabelle berücksichtigt. So hab ich das mal in einem guten Beitrag gelesen, den ich leider nicht mehr finde ;-(