SQL Abfrage vergleich

[Sawfare]

Hallo habe in einer der Lösungen folgende Lösung. Darunter befindet sich meine Lösung:

Select Art_Id, Art_Nummer, Art_Bezeichnung, Art_Preis,
	(Select Sum(RgPos_Menge)
     	From RechnungPosition As RegPos
     	Where RgPos.RgPos_ArtID = Art_Id) As MengeGesamt,
    (Select Count(RgPos_Id)
    	From RechnunsPosition A RgPos
     	Where RgPos.RgPos_ArtID = Art_Id) As Anzahl
    From Atrikel;
    
    
Select a.Art_Id,
	a.Art_Nummer,
    a.Art_Bezeichnung,
    a.Art_Preis,
    Sum(r.RgPos_Menge) As MengeGesamt,
    Count(r.RgPos_Id) As Anzahl
    From Atrikel a
    Join RechnunsPosition r ON a.Art_Id = r.RgPos_ArtId;
    

 

Würde ich in dem Fall 100% der punkte bekommen? (Bitte ignoriert Tippfehler, es geht um die allgemeine Syntax).

[Whiz-zarD]

Deine Lösung funktioniert nicht, da du kein GROUP BY angegeben hast. SUM und COUNT können nur auf Gruppen ausgeführt werden. Darum wurde in der oberen Lösung jeweils ein Subselect genommen.

[Sawfare]

und wenn ich ein "Group By a.Art_Id" drann hänge?

[neinal]

Ohne Aufgabenstellung wird dir auch niemand sagen können, ob du die volle Punktzahl bekommst.

Der erste Unterschied, der mir auffällt ist schon mal, dass oben kein Join ist. Aber eine Where Bedigung.

Du hast einen Join gemacht. Und keine Where Bedingung.

Aber ohne Angabe was denn überhaupt gemacht werden soll, kann ich nicht sagen ob das richtig oder falsch ist ^^

[Sawfare]

Erstellen Sie eine SQL-Abfrage, die für jeden Artikel Folgendes ermittelt:

-Die Menge, die insgesamt verkauft wurde

-Die Anzahl der Rechnungspositionen

[Whiz-zarD]

vor 3 Minuten schrieb Sawfare:

und wenn ich ein "Group By a.Art_Id" drann hänge?

Wird dann auch nicht funktionieren, da 

a.Art_Nummer, 
a.Art_Bezeichnung, 
a.Art_Preis,

nicht gruppiert sind oder du die Werte nicht mit SUM, COUNT, etc. aggregierst.

[Saheeda]

@Sawfare

 

Warum erstellst du dir nicht einfach eine Datenbank mit ein paar Beispieldatensätzen und setzt deine Query rein?

Dann siehst du doch sofort, obs geht und wenn Nein, warum nicht.

[neinal]

vor 7 Minuten schrieb Sawfare:

Erstellen Sie eine SQL-Abfrage, die für jeden Artikel Folgendes ermittelt:

-Die Menge, die insgesamt verkauft wurde

-Die Anzahl der Rechnungspositionen

Danke. Bringt mich aber auch nicht weiter.

Weil ich nicht weiß was wo wie in deiner Datenbank steht.

Das ist so, als würde ich dir sagen, geh mir mal bitte ein Auto kaufen. Und wenn du fragst welches, sage ich dir "ein blaues"...^^

[Whiz-zarD]

vor 4 Minuten schrieb neinal:

Danke. Bringt mich aber auch nicht weiter.

Weil ich nicht weiß was wo wie in deiner Datenbank steht.

Das ist so, als würde ich dir sagen, geh mir mal bitte ein Auto kaufen. Und wenn du fragst welches, sage ich dir "ein blaues"...^^

Viel braucht man doch gar nicht verstehen.
Das sind halt zwei Tabellen: Artikel und Rechnungsposition und die Tabelle Rechnungsposition ist mit der Tabelle Artikel über die Spalte Art_Id verknüpft. Mehr muss man doch nicht wissen.

[Fauch]

vor 30 Minuten schrieb neinal:

Ohne Aufgabenstellung wird dir auch niemand sagen können, ob du die volle Punktzahl bekommst.

Der erste Unterschied, der mir auffällt ist schon mal, dass oben kein Join ist. Aber eine Where Bedigung.

Du hast einen Join gemacht. Und keine Where Bedingung.

Aber ohne Angabe was denn überhaupt gemacht werden soll, kann ich nicht sagen ob das richtig oder falsch ist ^^

Die "Where"-Bedingung ist in dem Fall auch ein JOIN, der wird zwar intern anders gebildet, bleibt aber ein JOIN.

[neinal]

Trotzdem geht es nicht um die Praxis. Sondern um die Prüfung. Und da ist nunmal wichtig, wie die Aufgabenstellung lautet. Er will ja schließlich wissen, ob er alle Punkte bekommen würde.

[Whiz-zarD]

Und die Antwort lautet nein, weil das SQL-Statement nicht mal ausführbar ist.

[Asura]

vor 45 Minuten schrieb Fauch:

Die "Where"-Bedingung ist in dem Fall auch ein JOIN, der wird zwar intern anders gebildet, bleibt aber ein JOIN.

Steht da where oder join?

Mag sein, dass es gleiche Ergebnisse gibt.. Aber ein where is kein join.

Auch in diesem Fall ist "where" kein "join".

Und Whiz-zarD, in der Aufgabenstellung kann immer noch etwas stehen, was er hier nicht angibt. Wir sollten alle Wissen, dass die schriftliche AP oftmals alles andere als sauber und einfach gestellt ist.

[Whiz-zarD]

vor 4 Minuten schrieb Asura:

Und Whiz-zarD, in der Aufgabenstellung kann immer noch etwas stehen, was er hier nicht angibt. Wir sollten alle Wissen, dass die schriftliche AP oftmals alles andere als sauber und einfach gestellt ist.

Ja, schon klar aber wie gesagt, das SQL-Statement ist nicht mal ausführbar. Da braucht man die Aufgabe nicht, um das zu erkennen. Interessant wird es erst, wenn das Statement ausführbar wäre. Außerdem kennt er die Lösung. Da braucht man ihn nun auch nicht eine Lösung vorschlagen.

vor 53 Minuten schrieb Fauch:

Die "Where"-Bedingung ist in dem Fall auch ein JOIN, der wird zwar intern anders gebildet, bleibt aber ein JOIN.

Den Satz verstehe ich nicht mal. Eine Where-Klausel ist kein Join. Die Where-Klausel wird in einem Subselect verwendet.

[neinal]

vor 6 Minuten schrieb Whiz-zarD:

Ja, schon klar aber wie gesagt, das SQL-Statement ist nicht mal ausführbar. Da braucht man die Aufgabe nicht, um das zu erkennen. Interessant wird es erst, wenn das Statement ausführbar wäre. Außerdem kennt er die Lösung. Da braucht man ihn nun auch nicht eine Lösung vorschlagen.

Das war auch nicht die Frage. Sondern, ob er alle Punkte bekommen würde.

Wenn man ihm keine Lösung vorschlagen braucht, dann braucht man ihm ja gar nicht antworten. Weil er ja schon ne Lösung hat... ^^ Was ist das denn für ein Quatsch.

[Fauch]

vor 17 Minuten schrieb Asura:

Steht da where oder join?

Mag sein, dass es gleiche Ergebnisse gibt.. Aber ein where is kein join.

Auch in diesem Fall ist "where" kein "join".

Und Whiz-zarD, in der Aufgabenstellung kann immer noch etwas stehen, was er hier nicht angibt. Wir sollten alle Wissen, dass die schriftliche AP oftmals alles andere als sauber und einfach gestellt ist.

In beiden Fällen wird das kartesische Produkt gebildet. Ob da WHERE oder JOIN steht ist zunächst einmal eine reine Frage der Syntax.

http://stackoverflow.com/questions/1018822/inner-join-on-vs-where-clause

Es gibt Unterschiede, wie die Statements intern von den DBMS abgehandelt werden, ist zunächst aber für die Prüfung irrelevant.

Die WHERE syntax ist übrigens in der IHK-Prüfung absolut akzeptiert.

[Whiz-zarD]

vor 7 Minuten schrieb Fauch:

In beiden Fällen wird das kartesische Produkt gebildet. Ob da WHERE oder JOIN steht ist zunächst einmal eine reine Frage der Syntax.

Wo siehst du ein Where?
Das einzige Where, was ich sehe, steckt im Subselect. Das ist aber kein Join...

Das war auch nicht die Frage. Sondern, ob er alle Punkte bekommen würde.

Und selbst dafür braucht man die Aufgabe nicht ...
Wie gesagt, interessant wird es erst, wenn das Statement auch ausführbar wäre. Ist es aber nicht. Folglich bekommt er nicht die volle Punktzahl. Frage beantwortet.

Bearbeitet 22. November 2016 von Whiz-zarD

[Fauch]

Das habe ich auch nicht gesagt.

Mir ging es um die Begründung: Es ist etwas anderes weil einmal ein WHERE und einmal ein JOIN dasteht.

Und das ist, auf IHK-Level, nunmal nicht definitiv richtig.

Beispiel:

SELECT User.name, ADRESSE.adresse

FROM USER, ADRESSE

WHERE USER.USERID = ADRESSE.USERFID

 

ist das gleiche wie

 

SELECT USER.name, ADRESSE.adresse

FROM USER

JOIN ADRESSE

ON User.USERID = ADRESSE.USERFID

 

Die Tatsache, dass die Queries das NICHT gleiche ergeben ist korrekt. Zu sagen, das ergibt sich automatisch daraus, dass einmal WHERE und einmal JOIN verwendet wurden, ist es nicht.

Bearbeitet 22. November 2016 von Fauch

[Whiz-zarD]

Du redest aber an der Aufgabe völlig vorbei. Das Where befindet sich in einem Subselect. Das hat nichts mit einem Join zu tun. Pro Ergebniszeile werden die Subselects aufgerufen und als Filter-Kriterium wird der Wert Art_Id aus der Ergebniszeile genommen.

Falls du es auch nicht so ganz mitbekommen haben solltest: Das obere Statement ist die offizielle Lösung und das untere Statement ist von @Sawfare. In der offiziellen Lösung gibt es also kein Join.

[Asura]

vor 1 Stunde schrieb Whiz-zarD:

Ja, schon klar aber wie gesagt, das SQL-Statement ist nicht mal ausführbar. Da braucht man die Aufgabe nicht, um das zu erkennen. Interessant wird es erst, wenn das Statement ausführbar wäre. Außerdem kennt er die Lösung. Da braucht man ihn nun auch nicht eine Lösung vorschlagen.

Wir sind in einem Forum und er fragt um Hilfe. Ein einfaches "nein, bekommst du nicht. Das ist nicht mal Ausführbar", ist zwar die Antwort auf die Frage.. Aber keine Antwort die ihm hilft.

Um vielleicht, in der Aufgabenstellung, verstecke "Fallen" zu finden, hätten wir gerne die Aufgabenstellung. Sollte nichts weiter als ein Copy&Paste sein, bzw schnelles abtippen.

Wie bereits gesagt: Die Aufgabenstellung der schriftlichen Prüfung ist teilweise mehr als nur unverständlich und leicht gestellt.

Ich weiß nicht, warum du da jetzt diskutierst? Wenn wir die Aufgabenstellung wollen, dann wollen wir diese, weil es für uns relevant ist. Ein einfaches "braucht man nicht", ist hier nicht wirklich ein Gegenargument.. Zumindest nicht in meiner Sicht.

Wenn etwas unklar ist - So denke ich -, sollte man das alles sauber formatieren und beantworten.

- Aufgabenstellung
- Eigene Lösung
- Musterlösung

Zitat

 

In beiden Fällen wird das kartesische Produkt gebildet. Ob da WHERE oder JOIN steht ist zunächst einmal eine reine Frage der Syntax.

http://stackoverflow.com/questions/1018822/inner-join-on-vs-where-clause

Es gibt Unterschiede, wie die Statements intern von den DBMS abgehandelt werden, ist zunächst aber für die Prüfung irrelevant.

Die WHERE syntax ist übrigens in der IHK-Prüfung absolut akzeptier

 

Und? Wenn geschrieben wird, WHERE ist hier ein JOIN, dann ist das schlichtweg falsch.

Zitat

( Die "Where"-Bedingung ist in dem Fall auch ein JOIN, der wird zwar intern anders gebildet, bleibt aber ein JOIN. )

Where != Join, egal in welcher Situation. Sollte er irgendwann mal in der bewerteten Lage sein, dass er etwas ähnliches gefragt wird und einfach nur sagt: "das WHERE ist in diesem Fall ein JOIN", ist es einfach schlichtweg falsch.

Auch wenn man es Versteht und sich Denken kann, was er mit dieser Aussage meint.. Ist diese schlichtweg falsch bzw. ungeschickt erklärt.

Da kann penibel drauf geachtet werden.. und das könnte/wird vll. ein paar Punkte kosten. Ist zwar unwahrscheinlich, dass man in diese Lage kommt.. Aber wenn dann, sollte man das von Anfang an sauber erklären.

Vielleicht bin ich da etwas zu penibel, mir ging man aber extremst auf die Nüsse, wenn ich etwas so vereinfach erklärt habe.

[Whiz-zarD]

vor 7 Minuten schrieb Asura:

Wir sind in einem Forum und er fragt um Hilfe. Ein einfaches "nein, bekommst du nicht. Das ist nicht mal Ausführbar", ist zwar die Antwort auf die Frage.. Aber keine Antwort die ihm hilft.

Bis jetzt hat er noch um keine Hilfe gefragt. Die Frage lautete, ob er die volle Punktzahl bekommt. Mehr nicht und die Antwort ist Nein, aus besagten Gründen. Alles andere kann man immer noch schauen. Das muss aber vom Threadersteller selbst kommen. Der Threadersteller hat davon nichts, wenn man ihn erst mal bis zur Unterhosengröße ausquetscht und dann Informationen bekommt, nach denen er gar nicht gefragt hat.

[neinal]

Ich glaube wir sind uns einig, dass wir uns nicht einig sind.

[Sawfare]

vor 2 Stunden schrieb Whiz-zarD:

Bis jetzt hat er noch um keine Hilfe gefragt. Die Frage lautete, ob er die volle Punktzahl bekommt. Mehr nicht und die Antwort ist Nein, aus besagten Gründen. Alles andere kann man immer noch schauen. Das muss aber vom Threadersteller selbst kommen. Der Threadersteller hat davon nichts, wenn man ihn erst mal bis zur Unterhosengröße ausquetscht und dann Informationen bekommt, nach denen er gar nicht gefragt hat.

Danke für deine Beteiligung am Thread, meine erste Frage auf deinen Post hast du allerdings noch nicht beantwortet:

 

Was wäre, wenn ich "Group by a.Art_Id" drann hänge? 

 

-> Falls du der Meinung bist, dass es ein Sub-Select sein MUSS, woher weiß ich das? 

[Whiz-zarD]

vor 26 Minuten schrieb Sawfare:

Danke für deine Beteiligung am Thread, meine erste Frage auf deinen Post hast du allerdings noch nicht beantwortet:

 

Was wäre, wenn ich "Group by a.Art_Id" drann hänge?

Darauf habe ich geantwortet :

vor 6 Stunden schrieb Whiz-zarD:

Wird dann auch nicht funktionieren, da 

a.Art_Nummer, 
a.Art_Bezeichnung, 
a.Art_Preis,

nicht gruppiert sind oder du die Werte nicht mit SUM, COUNT, etc. aggregierst.

 

vor 27 Minuten schrieb Sawfare:

-> Falls du der Meinung bist, dass es ein Sub-Select sein MUSS, woher weiß ich das? 

Weil dies mit ANSI SQL der beste Weg ist. Einige DBMS haben noch analytische Funktionen, mit denen man das auch noch hinbekommen kann aber die zählen wohl in der Prüfung nicht. Man könnte es auch mit ANSI SQL so hingekommen, wie du denkst, aber das wäre eher ein workaround und nicht mehr wirklich semantisch lesbar, weil man einige Annahmen treffen müsste. Die Lösung schreibe ich später noch hier rein. Ich bin gerade mit einem Smartphone unterwegs und mit code-editierungen hat mein Smartphone so einige Probleme. 

[Whiz-zarD]

So, du müsstest dein Statement folgendermaßen ändern:

SELECT
    a.Art_Id,
    a.Art_Nummer,
    a.Art_Bezeichnung,
    a.Art_Preis,
    SUM(r.RgPos_Menge) As MengeGesamt,
    COUNT(r.RgPos_Id) As Anzahl
FROM
    Artikel a
    INNER JOIN RechnungsPosition r 
        ON a.Art_Id = r.RgPos_ArtId
GROUP BY
    a.Art_Id,
    a.Art_Nummer,
    a.Art_Bezeichnung,
    a.Art_Preis
;

Der Grund für die Änderungen ist, dass Aggregationsfunktionen, wie z.B. COUNT, SUM, MIN, MAX, AVG nur auf Gruppierungen angewendet werden können. D.h. wir müssen Gruppen bilden. Wir bilden die Gruppen über Art_Id, Art_Nummer, Art_Bezeichnung und Art_Preis.

Mit dieser Lösung haben wir aber das Problem, wenn wir eine weitere Spalte ausgeben wollen, müssen wir die Spalte auch in die Gruppierung einbeziehen. Man muss das Statement also an zwei Stellen anpassen und das finde ich persönlich nicht so toll. Man müsste sich aber mal den Explain-Plan anschauen, welche Lösung performanter ist. Das weiß ich gar nicht so richtig.

Bearbeitet 22. November 2016 von Whiz-zarD