rekursive abfragen

Mahlzeit :slight_smile:

ist es möglich rekursive-SQL abfragen mit postgres zu verwenden?
Wenn ja, wüsste jemand eine Quelle bei der ich mich informieren kann?
Ich habe im Online-Handbuch und auch bei google nichts gefunden.


Danke für eure Mühe!

Crypi

Du kannst z.B. Funktionen rekursiv aufrufen … bis der Stack voll ist :wink:
Also im Prinzip ja, aber in SQL selber wird das nichts.

hmm, das Problem an dem ich zur Zeit sitze ist nämlich folgendes:

ich habe eine tabelle:

orga

personr | name | vorgesetzter

1 | chef1 | null
2 | chef2 | null
3 |AbtLei1 |1
4 | MA1 | 3
5 | AbtLei2| 2
6 |MA2 | 5
7 | MA3 | 5


ich möchte jetzt z.b. alle Untergebenen von chef2 heraufinden.
Wobei die Hirarchie noch deutlich tiefer gehen kann über eine unbestimmte Anzahl von Stufen.

Wie bekomme ich denn alle Untergebenen?

Dafür fehlt mir eine Lösung…
Nach Möglichkeit ohne Funktionen oder ähnliches.

Crypi

Gibt es, Google kennt sie.

postgresql with recursive - Google-Suche
Ergebnisse 1 - 10 von ungefähr 509.000 für postgresql with recursive. (0,17 Sekunden)

U.a., 2. Treffer:

Dealing With Recursive Sets With PL/PGSQL - Merlin Moncure’s PostgreSQL blog


Andreas

ich hab wohl mit meinen deutschen suchbegriffen nicht soviel erfolg gehabt…

sollte ich zukünftig ändern… werds mir angucken.


danke!

edit: soweit ich das übersehen kann liegen dort aber überall funktionen zugründe nicht wahr?
mit reinem sql geht es nicht?


Crypi

Was stört Dich daran?

Im SQL?? gibt es IIRC etwas mit Recursion, und in David Fetters PWN hab ich auch mal was dazu gelesen, daß man da dran arbeitet. Frag mich jetzt aber nicht nach Details…


Andreas

naja, aus meiner sicht spalte ich dabei dann die busines-logik. dann steckt sozusagen logik in der datenhaltungsschicht…

ich versuche eigentlich, je nach möglichkeit, datenhaltung, logik, und ausgabe strikt von einander zu trennen, um eine einfachere wartung zu ermöglichen.

rekursion wäre da ein schöner ansatz. ich habe auch gelesen, dass es für eine kommende version geplant ist. allerdings stand da dann auch was von “next major release 7.4”… naja war wohl schon etwas älter.

hmmm dann muss ich mir jetzt mal überlegen wie ich das mache. danke für eure hilfe!

Crypi

Hä? plpgsql-Funktionen (oder auch in anderen Sprachen) laufen im Kern der DB. Das ist faktisch nur eine Erweiterung der DB.

rekursion wäre da ein schöner ansatz. ich habe auch gelesen, dass es für eine kommende version geplant ist. allerdings stand da dann auch was von “next major release 7.4”… naja war wohl schon etwas älter.

Himmel, wo hast Du das gelesen? Aktuell ist 8.2, 8.3 steht vor der Tür.

hmmm dann muss ich mir jetzt mal überlegen wie ich das mache. danke für eure hilfe!

Crypi

Schau Dir an, was mit Stored Procedures alles so geht. Du wirst begeistert sein.


Andreas

ja genau… ich habe eine php-applikation. dort steckt eben die business-logik.
wenn ich nun teile davon (von der logik) in die DB auslagere habe ich einen höheren wartungsaufwand. gleiches problem habe ich auch mit triggern und ähnlichem und verzichte soweit es geht darauf.


ja… sehr alt… deswegen dachte ich ja, dass es jetzt evtl schon eingeführt ist… da ich auch 7.4 nutze.


eine menge, dass weiß ich, aber auch hier sehe ich das oben genannte problem.

Andreas

[quote=“Crypi”]ja genau… ich habe eine php-applikation. dort steckt eben die business-logik.
wenn ich nun teile davon (von der logik) in die DB auslagere habe ich einen höheren wartungsaufwand. gleiches problem habe ich auch mit triggern und ähnlichem und verzichte soweit es geht darauf.

Autsch. Vermutlich machst Du auch referentielle Integrität etc. in PHP. Das erinnert an MySQL Reference Manual for version 3.23.37.

Andreas

autsch?

diese punkte meinte ich nun nicht, aber auch diese gründe sprechen dagegen.


mir geht es wirklich darum, dass die einzelnen aufgabengebiete strikt getrennt sind. wenn nun z.b. eine andere person an meiner applikation weiterarbeiten soll wundert sie sich möglicherweise über seltsame effekte, die plötzlich auftreten wenn sie etwas ändert. es wirkt sich dann eben nicht nur die ‘logik’ in php auf die daten aus, sondern eben auch die stored procedures, trigger oder was auch immer, die in der datenbank dafür sorgten, dass mit den daten alles so geschah wie es bisher gewünscht war.

die gründe aus deinem link sprechen ebenso dagegen. auch wenn ich trotzallem auf foreign keys nicht immer verzichte bzw. verzichtet habe.

Crypi

Ich hab wenig Lust auf Grundsatzdiskussion dazu, aber offensichtlich nutzt Du die DB nur und ausschließlich als Zettelkasten.
Dinge wie Trigger und Stored Procs können das Leben erheblich vereinfachen, und außerdem auch die Anwendungsprogramme. Sie können von komplett stupiden Dingen wie der Prüfung auf RI-Bedingungen oder anderen Dingen befreien. Und sie sorgen für Datenkonsistenz.

Aber okay, ich kenne Dein Einsatz nicht. Wenn Du damit glücklich bist, auf 99% Funktionalität zu verzichten und das lieber selber neu zu erfinden, dann mag mir das egal sein…

Andreas

schade, mir würds spaß machen :slight_smile:


danke für deine unterstützung!

Crypi