Verschachtelte SQL Abfrage

[Walter Landwehr]

Hallo SQL Spezis,

ich habe eine Tabelle (Buchhaltung) worin es die Felder Kontonummer und Gegenkontonummer gibt.

Ich möchte nun in einem SQL Statement ermitteln alle Kontonummern und Gegenkontonummer die in den Datensätzen vorkommt.
Für die Kontonummer ist es einfach.

Delphi-Quellcode:

SELECT Kontonummer, COUNT(Kontonummer)
FROM tbl_buchhaltung
GROUP BY Kontonummer
HAVING ( COUNT(Kontonummer) > 0 )

Wir mache ich es aber mit Kontonummer und Gegenkontonummer.

Jedes Konto darf als Ergebnis nur einmal vorkommen. (siehe Anlage)

[jobo]

so ungefähr

Code:

select kontonummer, sum(anzahl) from (
seölct kontonummer, count(*) as Anzahl from tabelle group by kontonummer
union all
seölct gegenkontonummer, count(*) from tabelle group by gegenkontonummer
) x

[mkinzler]

SQL-Code:

select 
  distinct konto 
from
  (
      select distict konto from <tabelle>
    union
      select distinct gegenkonto as konto from <Tabelle>
  );

[TBx]

Den Union-Ansatz würde ich auch wählen, ich verstehe die Aufgabe so, dass alle Konten herausgefunden werden sollen, egal ob sie als Konto oder als Gegenkonto verwendet wurden.
Allerdings kann man sich hier den Subselect sparen, da der Union als default ein UNION DISTINCT ist.

SQL-Code:

      select distinct konto from tbl_buchhaltung
    union
      select  gegenkonto from tbl_buchhaltung

[jobo]

Soll denn nicht gezählt werden?

[mkinzler]

Ist m.E. nicht notwendig. Dient wohl nur dazu Dupletten auszufiltern, was durch das DISTINCT ja gemacht werden sollte.

[p80286]

Zitat:

Zitat von TBx (Beitrag 1385315)

Den Union-Ansatz würde ich auch wählen, ich verstehe die Aufgabe so, dass alle Konten herausgefunden werden sollen, egal ob sie als Konto oder als Gegenkonto verwendet wurden.

das wäre eine Möglichkeit, was aber wenn implizit gefragt wurde ob eine Kontonummer sowohl ein Konto als auch ein Gegenkonto repräsentiert?

Gruß
K-H

[TBx]

Zitat:

Zitat von p80286

.. was aber wenn implizit gefragt wurde ob eine Kontonummer sowohl ein Konto als auch ein Gegenkonto repräsentiert?

Was nun genau benötigt wird, kann uns nur der TE sagen.

[Walter Landwehr]

benötigt wird wie es mkinzler schon geschrieben hat.

[Walter Landwehr]

Bei diesen Statement:

Delphi-Quellcode:

select 
   distinct kontonummer
from
   (
       select distinct kontonummer from tbl_buchhaltung
     union
       select distinct gegenkontonummer as kontonummer from tbl_buchhaltung
   );

kommt diese Fehlermeldung:

Invalid token.
Dynamic SQL Error.
SQL error code = -104.
Token unknown - line 1, column 1.
distinct

[p80286]

Zitat:

Zitat von Walter Landwehr (Beitrag 1385354)

Bei diesen Statement:

Delphi-Quellcode:

select 
   distinct kontonummer
from
   (
       select distinct kontonummer from tbl_buchhaltung
     union
       select distinct gegenkontonummer as kontonummer from tbl_buchhaltung
   );

kommt diese Fehlermeldung:

Invalid token.
Dynamic SQL Error.
SQL error code = -104.
Token unknown - line 1, column 1.
distinct

???? Hast du da vllt. irgendwelchen zeichenschrott mit dabei?
Die Abfrage sollte so eigentlich auf jeder (mir) bekannten SQL-DB laufen. Ggf. noch einmal Zeichen füre Zeichen neu einhacken?

Und oder das Format auf weniger schön ändern?

SQL-Code:

select distinct kontonummer
from    (select distinct kontonummer from tbl_buchhaltung
         union
         select distinct gegenkontonummer as kontonummer from tbl_buchhaltung);

Gruß
K-H

[jobo]

Zumindest in Beitrag #3 und gequotet in #4 steht einmal 'distict' statt 'distinct'.
Im Quote von Walter Landwehr steht es zwar nicht so, aber wer weiß, wo nun der copy / Paste Fehler liegt.

Es muss 'distinct' lauten.

Außerdem "as kontonummer " ist unnötig.
Wenn schon einen überflüssigen alias spendieren, dann lieber nach der schließenden Klammer.

[Walter Landwehr]

Danke an alle nun funktioniert es.

Delphi-Quellcode:

select 
   distinct kontonummer
from
   (
       select distinct kontonummer from tbl_buchhaltung
     union
       select distinct gegenkontonummer as konto from tbl_buchhaltung
   );

[jobo]

" as konto " macht dann spätestens jetzt in dieser Form keinen Sinn mehr. (auch wenn es immer noch funktioniert)

und ohne zählen zu müssen, sollte dann das reichen:

Delphi-Quellcode:

select kontonummer from tbl_buchhaltung
     union
select gegenkontonummer from tbl_buchhaltung

[p80286]

Zitat:

Zitat von jobo (Beitrag 1385372)

" as konto " macht dann spätestens jetzt in dieser Form keinen Sinn mehr. (auch wenn es immer noch funktioniert)

und ohne zählen zu müssen, sollte dann das reichen:

Delphi-Quellcode:

select kontonummer from tbl_buchhaltung
     union
select gegenkontonummer from tbl_buchhaltung

Richtig, aber wenn vorher

SQL-Code:

as kontonummer

zu einem Fehler geführt hat, wäre es interessant, warum. Unter Oracle ist

SQL-Code:

"Kontonummer"

ja nicht das gleiche wie

SQL-Code:

Kontonummer

. Liegt hier unter Umständen eine ähnliche Animosität vor?

Gruß
K-H

[jobo]

Die aufgetretenen Fehler halte ich für Fehler in der Kommunikation hier in DP. Wahrscheinlich war Dein Tipp schon ganz richtig.

Die Aliase in einem Union sind ab dem ersten Union schlicht überflüssig, sie können halt auch angegeben werden, zählen tut einzig der Satz von Feldnamen aus dem ersten Statement.
Man könnte vielleicht noch argumentieren, dass bei größeren Union so etwas "Dokumentation" entsteht.
Feld Aliase aber in verschiedenen Selects des Union unterschiedlich zu nennen, ist sinnfrei- auch wenn es keinen Fehler wirft.
Ein Union erwartet lediglich gleiche Feldanzahl und Typ, Namen sind wurscht, namengebend sind die Spaltenname oder Aliase aus dem ersten Select. Wahrscheinlich macht er wenn möglich sogar implizite Typkonvertierung, würde ich mich allerdings nie drauf verlassen.

Die "" Sache bei Oracle dient einfach der Möglichkeit exakte Feldnamen mit Umlauten, Chinesisch usw. verwenden zu können. Dann wird halt nicht mehr case insensitiv gearbeitet, sondern buchstabengetreu der Feldname verwendet. Ich denke das gibt es so oder mit etwas anderer Syntax auch bei vielen anderen Herstellern, Backticks (`fElD naME`) bspw by mysql.
Ich halte da nichts von, arbeite quasi "historisch" mit englisch ASCII Alphabet.

Ich habe in meinen Posts einfach Anführungszeichen als Quoteindikator verwendet, die waren aber um den gesamten Aliasbegriff "as kontonummer". Dass einer der Aliase einen Fehler proviziert haben soll, ist mir nicht bewusst. Meine Anmerkungen drehten sich lediglich um Sinn und Verständnis des SQL Konstrukts.

[mkinzler]

Firebird verwendet die "" im gleichen Sinne wie Oracle. Durch das Quoten werden Bezeichner case-sensitiv.

Ich verwende in diesem Fall gerne die Aliases, wenn diese auch nicht notwendig sind.

[p80286]

Zitat:

Zitat von jobo (Beitrag 1385434)

Man könnte vielleicht noch argumentieren, dass bei größeren Union so etwas "Dokumentation" entsteht.

:stupid: Manchmal hab ich den Eindruck, daß sich bei dem einen oder anderen Job ähnliche Denkschemata heraus bilden. :stupid:

Gruß
K-H

[nahpets]

Na klar, man macht im Laufe der Jahre halt die Erfahrung, dass lesbarer Code (der möglichst der "Muttersprache" oder dem eigenen Denkschema entspricht, auch nach Jahren noch verstanden wird. Man liest es halt wie einen Text aus 'nem Handbuch, 'ne Inhaltsangabe einer Kurzgeschichte ...

Einmal lesen und man weiß nach Jahren sofort, was man damals da so "verbrochen" hat und kann sofort da einsteigen, wo man irgendwann aufgehört hat. Man braucht weder lange zu suchen und zu grübeln: "Was der Henker hab' ich mir dabei gedacht". Oder auch nicht in eine (hoffentlich vorhandene) Dokumentation, Analyse, sonstige Vorgabe schauen. Beim Lesen wird sofort klar, was gemeint, was gewollt und was gemacht wurde. Und es wird einem recht schnell klar, ob die drei auch zum gleichen Ergebnis führen. Wenn nicht, macht man da weiter, wo man mal aufgehört hat.

Könnte man das als "Debuggen durch Verständlichkeit" bezeichnen?

[jobo]

Zitat:

Zitat von p80286 (Beitrag 1385450)

:stupid: Manchmal hab ich den Eindruck, ..

Zitat:

Zitat von nahpets (Beitrag 1385468)

.. man macht im Laufe der Jahre halt die Erfahrung,
--
Könnte man das als "Debuggen durch Verständlichkeit" bezeichnen?

Also das wichtigste ist natürlich die Erfahrung, dass man sich nicht mehr alles merken kann, ab einem gewissen Alter! :)

Debuggen ist so eine Sache bei SQL. Die Statements sind meist relativ übersichtlich. Die eigentlichen Bugs hängen ja oft in den Datensätzen (besonders bei Importen)-
Für mich auch ein Grund, alles solgane mit SQL zu machen- was auch wunderbare Prüfmöglichkeiten bietet-, bis es läuft und validierte Daten liefert, dann erst ins Programm.

[nahpets]

Zitat:

Zitat von jobo (Beitrag 1385680)

Für mich auch ein Grund, alles solgane mit SQL zu machen- was auch wunderbare Prüfmöglichkeiten bietet-, bis es läuft und validierte Daten liefert, dann erst ins Programm.

Ja, ganz klar, erst wenn's auf der Datenbank vollkomen korrekt funktioniert, wird's ins Programm aufgenommen.

Zitat:

Zitat von jobo (Beitrag 1385680)

Debuggen ist so eine Sache bei SQL. Die Statements sind meist relativ übersichtlich. Die eigentlichen Bugs hängen ja oft in den Datensätzen (besonders bei Importen)-

Mit dem Debuggen meinte ich eigentlich auch mehr so: "Die eigenen Gedankengänge nochmal hinterfragen, steht da das, was gemeint und gewollt war." Weniger, ob es aus technischer Sicht korrekt ist.

Je komplexer SQL wird, um so größer ist die Wahrscheinlichkeit, dass sich logische Fehler einschleichen, auch dann, wenn das, was man da gebaut hat, technisch vollkommen fehlerfrei funktioniert.

Also eher die Suche nach abstrakten, logischen Fehlern.
Technische (syntaktische) Fehler bekommt man ja beim Ausführen sofort "um die Ohren gehauen".

In PL/SQL-Scripten größeren Umfanges kann dann die Fehlersuche schonmal etwas aufwändiger werden ;-)

[jobo]

Zitat:

Zitat von nahpets (Beitrag 1385697)

Mit dem Debuggen meinte ich eigentlich auch mehr so: "Die eigenen Gedankengänge nochmal hinterfragen, steht da das, was gemeint und gewollt war." Weniger, ob es aus technischer Sicht korrekt ist.

Technische (syntaktische) Fehler bekommt man ja beim Ausführen sofort "um die Ohren gehauen".

In PL/SQL-Scripten größeren Umfanges kann dann die Fehlersuche schonmal etwas aufwändiger werden ;-)

Ok, vielleicht "prebuggen"? ;)
Ja, Syntaxfehler sind die schönsten, solange die Fehlermeldung hablwegs fair ist.
Eine logischer Fehler in einer Auswertung kann es dann doch in sich haben. (Siehe Thread nebenan, gleicher Titel)

Und PL/SQL, da nehme ich mir dann doch gerne mal den Debugger.

[p80286]

Zitat:

Zitat von nahpets (Beitrag 1385697)

Mit dem Debuggen meinte ich eigentlich auch mehr so: "Die eigenen Gedankengänge nochmal hinterfragen, steht da das, was gemeint und gewollt war."

:thumb:

vielleicht noch um "..und versteht die DB was ich gemeint habe" ergänzen.

Gruß
K-H

[nahpets]

Ja, da ist durchaus was dran.

Die DB versteht das, was ich schreibe, während ich beim Lesen meines geschriebenen ggfls. verstehe, was ich meinte, auch wenn das so explizit dort nicht steht.

Die DB nimmt halt alles wörtlich, wir Menschen tendieren eher zum Interpretieren / zwischen den Zeilen lesen.