Ankündigung

Einklappen
Keine Ankündigung bisher.

MAX() in einer foreach Schleife

Einklappen

Neue Werbung 2019

Einklappen
Dieses Thema ist geschlossen.
X
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #46
    Zitat von protestix Beitrag anzeigen

    Gerne
    PHP-Code:
    SELECT g.idg.angebot_idMAX(g.preiseingabe) AS Höchstgebotg.kunde AS `abgegeben von`, FROM_UNIXTIME(min(g.`timestamp`)) AS `Datum Uhrzeit`, a.titel AS `Artikel`
    FROM gebote g
    INNER JOIN gebote t ON 
    (g.angebot_id=t.angebot_id AND g.preiseingabe>t.preiseingabe) OR
    (
    g.preiseingabe=t.preiseingabe AND g.timestamp<t.timestamp)
    LEFT JOIN angebote a ON g.angebot_id a.Auktionsnummer
    GROUP BY g
    .angebot_ida.titel 
    *getestet, jedoch ohne Gewähr auf Richtigkeit der Ausgabe

    Funktioniert ebenfalls nur bei abgeschaltetem ONLY_FULL_GROUP_BY. Überprüfe das mal bitte mit
    Code:
    SELECT @@session.sql_mode;
    . Insofern ist das Ergebnis möglicherweise nur zufällig richtig.

    Ergänzg.: Hat sich inzwischen bestätigt. Fügt man die nach (lt. protestix ) "Standard" bzw. eingeschaltetem ONLY_FULL_GROUP_BY (was ja dann dem "Standard" entspräche) erforderlichen Spalten im GROUP BY hinzu und fügt man weitere Gebote in die betr. Tabelle ein, wird die Gruppierung unter Einschluß von 'kunde' durchgeführt. Man sieht am Ergebnis der Abfrage dann sehr deutlich, daß "King Ich" im Abfrageergebnis zufällig über dem Eintrag zu "Maxi" steht. Deshalb nimmt das SQL "in seiner Not" (weil es ja nicht alle Bieter in ein einziges Feld quetschen kann) diesen.

    Übrigens: Netter Versuch, protestix !

    Kommentar


    • #47
      Zitat von king-ich Beitrag anzeigen
      Das Lustige, (oder vielmehr Traurige): Seit über 10 Jahren bettel ich nach einem Bildungsgutschein für den Bereich Webentwicklung, ohne Erfolg.
      Nicht bettel! Eigeninitiative... es gibt heute soviele Möglichkeiten sich in dem Bereich weiterzubilden. Und insbesondere lernst du in der Branche nie aus.

      Zitat von hausl Beitrag anzeigen
      Leider ja, Stackoverflow-Prinzip. Egal wie scheisse dein Code ist und wie viele Fehler und Lücken du darin hast.. wenn du keine "Antwort auf die Frage" gibst wirst du gerügt. Ist mir selbst schon passiert, dann habe ich es dort gelassen. So viel zu deren Eingangs-Slogan "... for developers to learn". Na eh bei gnadenlosen Q&A lernt man sicher viel.. /Irnoie-Off .
      Das ist die Kehrseite der Medaille. Wenn ich mir hier so manches Thread anschaue frag ich mich auch.

      Zitat von protestix Beitrag anzeigen

      Gerne
      PHP-Code:
      SELECT g.idg.angebot_idMAX(g.preiseingabe) AS Höchstgebotg.kunde AS `abgegeben von`, FROM_UNIXTIME(min(g.`timestamp`)) AS `Datum Uhrzeit`, a.titel AS `Artikel`
      FROM gebote g
      INNER JOIN gebote t ON 
      (g.angebot_id=t.angebot_id AND g.preiseingabe>t.preiseingabe) OR
      (
      g.preiseingabe=t.preiseingabe AND g.timestamp<t.timestamp)
      LEFT JOIN angebote a ON g.angebot_id a.Auktionsnummer
      GROUP BY g
      .angebot_ida.titel 
      *getestet, jedoch ohne Gewähr auf Richtigkeit der Ausgabe
      Der Query ist unlogisch aufgebaut. Wenn ich für alle beendeten Angebote das maximal Gebot haben will, sollte die Anfrage doch schonmal mit der Tabelle angebote los gehen und nicht als LEFT JOIN am Ende sitzen. Gibt es Gebote für nicht existente Angebote?!
      Angebote also hochzeihen und dann mit INNER JOIN (nur Angebote mit Geboten) bzw. LEFT JOIN (auch Angebote auf die nicht geboten wurde) weiter machen.
      Ansonsten passt das von der Logik. Auf den Ansatz wäre ich nicht gekommen.

      Kommentar


      • #48
        Zitat von erc Beitrag anzeigen

        Nicht bettel! Eigeninitiative... es gibt heute soviele Möglichkeiten sich in dem Bereich weiterzubilden. Und insbesondere lernst du in der Branche nie aus.



        Das ist die Kehrseite der Medaille. Wenn ich mir hier so manches Thread anschaue frag ich mich auch.



        Der Query ist unlogisch aufgebaut. Wenn ich für alle beendeten Angebote das maximal Gebot haben will, sollte die Anfrage doch schonmal mit der Tabelle angebote los gehen und nicht als LEFT JOIN am Ende sitzen. Gibt es Gebote für nicht existente Angebote?!
        Angebote also hochzeihen und dann mit INNER JOIN (nur Angebote mit Geboten) bzw. LEFT JOIN (auch Angebote auf die nicht geboten wurde) weiter machen.
        Ansonsten passt das von der Logik. Auf den Ansatz wäre ich nicht gekommen.
        Nur daß es eben nicht funktioniert - in diesem Falle, weil es gegen die ONLY_FULL_GROUP_BY-Beschränkung verstößt und in diesem Falle die Beschränkung auch völlig zu Recht zu beachten wäre.

        Statt von "Hochziehen" und INNER oder LEFT JOIN zu reden, schreib die Abfrage auf und probier sie aus. Du wirst sehen, ohne sub-select geht es nicht. Begründet habe ich das nun wirklich schon zu genüge.

        Kommentar


        • #49
          Zitat von marie123 Beitrag anzeigen
          Nur daß es eben nicht funktioniert - in diesem Falle, weil es gegen die ONLY_FULL_GROUP_BY-Beschränkung verstößt und in diesem Falle die Beschränkung auch völlig zu Recht zu beachten wäre.
          Sry, ich hab eine andere Anfrage vor Augen gehabt. Dieser self JOIN auf die Angebote um das maximal Gebot zu filtern hat es mir angetan. Der liefert das gewüschnte Ergebnis. Das GROUP BY und die Aggregat-Funktion sind in der Abfrage komplett überflüssig. Deswegen hab ich die gar nicht wahrgenommen und deswegen liefert der Query trotzdem auch das richtige Ergebnis.
          (Der Vergleich muss mit >= gemacht werden, ansonsten funktioniert der Query nicht wenn nur ein Gebot geacht wurde).

          *edit* obwohl das OR zerhauts u.U...
          *edit2* ok, kann so doch nicht funktionieren... g.preiseingabe>t.preiseingabe ist mehrfach wahr pro Auktion, aber auch nie füs höchste Gebot.

          Kommentar


          • #50
            Zitat von erc Beitrag anzeigen

            Sry, ich hab eine andere Anfrage vor Augen gehabt. Dieser self JOIN auf die Angebote um das maximal Gebot zu filtern hat es mir angetan. Der liefert das gewüschnte Ergebnis. Das GROUP BY und die Aggregat-Funktion sind in der Abfrage komplett überflüssig. Deswegen hab ich die gar nicht wahrgenommen und deswegen liefert der Query trotzdem auch das richtige Ergebnis.
            (Der Vergleich muss mit >= gemacht werden, ansonsten funktioniert der Query nicht wenn nur ein Gebot geacht wurde).

            *edit* obwohl das OR zerhauts u.U...
            Ich verstehe nur noch Bahnhof. Sei mir nicht böse, aber warum postest du nicht einfach die fertige Abfrage, dann kann man die testen und alles ist klar. Beim Testen bitte unbedingt noch mind. 2 weitere Gebote für den Bieter Maxi erfassen, damit man überprüfen kann, ob das Ergebnis ggfs. bei abgeschaltetem ONLY_FULL_GROUP_BY (falls Group by überhaupt verwendet wird) evtl. zufällig richtig ist.

            Kommentar


            • #51
              Zitat von marie123 Beitrag anzeigen
              Ich verstehe nur noch Bahnhof. Sei mir nicht böse, aber warum postest du nicht einfach die fertige Abfrage, dann kann man die testen und alles ist klar.
              Ich mach sowas meistens im Kopf. Da gibts aber manchmal auch "Ausführungsfehler". Ich hatte hier grade ein massiven Denkfehler. Vereinfacht für eine Auktion betrachtet... angenommen wir haben 3 Gebote {1€, 2€, 3€}. Daraus wird das Kreuzprodukt mit sich selbst gebildet (der inner join).

              {
              (1€, 1€)
              (1€, 2€)
              (1€, 3€)
              (2€, 1€)
              (2€, 2€)
              (2€, 3€)
              (3€, 1€)
              (3€, 2€)
              (3€, 3€)
              }

              Und diese Tuppel werden gefiltert "erstes Element" > "zweites Element" (ON Klausel g.preiseingabe>t.preiseingabe). Hier hatte ich grade die Annhame, dass da genau ein Tuppel überig bleibt (3€, 3€). Was natürlich absoluter quatsch ist! Da kommt (2€, 1€), (3€, 1€), (3€, 2€) raus und der Query kann so nicht funktionieren... (Wäre die Annahme korrekt würde der Query wunderbar funktionieren )

              Kommentar


              • #52
                Zitat von erc Beitrag anzeigen

                Ich mach sowas meistens im Kopf. Da gibts aber manchmal auch "Ausführungsfehler". ...

                Und diese Tuppel werden gefiltert "erstes Element" > "zweites Element" (ON Klausel g.preiseingabe>t.preiseingabe). Hier hatte ich grade die Annhame, dass da genau ein Tuppel überig bleibt (3€, 3€). Was natürlich absoluter quatsch ist! Da kommt natürlich (2€, 1€), (3€, 1€), (3€, 2€) raus und der Query kann so nicht funktionieren... (Wäre die Annahme korrekt würde der Query wunderbar funktionieren )
                Hart gesagt: Hätte, wenn und würde bringt uns hier nicht weiter. Es ist ja nicht so, als wenn ich nicht selbst schon nach Möglichkeiten gesucht hätte, das GROUP BY komplett zu umgehen. Aber das, was da - ebenfalls "meistens im Kopf" - rauskam, lief dann i.d.R. doch auf einen verschachtelten Select hinaus. Also habe ich nichts davon wirklich weitergetrieben. Schau doch mal, ob du nicht doch deinen Gedanken zu Papier bzw. in Source-Code bringen kannst.

                Kommentar


                • #53
                  Zitat von marie123 Beitrag anzeigen
                  Es ist ja nicht so, als wenn ich nicht selbst schon nach Möglichkeiten gesucht hätte, das GROUP BY komplett zu umgehen.
                  Es gibt nur eine Möglichkeit in SQL eine Aggregatfunktion zu nutzen, ohne group by einzusetzen:
                  Die Ausschließliche Nutzung von Aggregatfunktionen für jede Ausgabespalte.

                  Diese Frage kann eigentlich nur aufkommen, wenn man fehlerhaft konfiguriertes mysql einsetzt, folglich manchmal Glück hat bzw. nicht sieht, wann das Kleingedruckte zutrifft und wann nicht, also "zufällig" ein richtiges Ergebnis erhält und (deshalb vielleicht) die Problematik noch nicht verstanden hat.

                  Aggregat Funktionen können nur sinnvolle Ausgaben produzieren, wenn weitere, vorhandene Ausgabespalten gruppiert werden.

                  Kommentar


                  • #54
                    Zitat von marie123 Beitrag anzeigen
                    Schau doch mal, ob du nicht doch deinen Gedanken zu Papier bzw. in Source-Code bringen kannst.
                    Mit Mysql ohne Subqueries? Seh ich keine Lösung... deswegen fand ich den Query so interessant. Das ich da grade komplett verpeilt war, anderes Thema Mit Subqueries? Sry, *schnarch*... da kann ich dir x Varianten aus dem Hut zaubern. Ich könnte dir jetzt noch was mit CTEs oder VIEWs anbieten, aber das ist die Subquery-Variante in grün.

                    Kommentar


                    • #55
                      Zitat von marie123 Beitrag anzeigen
                      MySQL bietet spätestens seit Versionen höher als 5.7.5 die Möglichkeit, die Einstellung ONLY_FULL_GROUP_BY zu deaktivieren, was die Ausführung fehlerhafter Abfrage wie die oben zuletzt wiedergegebene ermöglicht. Dies ist also kein "Fehler" und auch keine "Standard-Verletzung", sondern lediglich eine Wahlmöglichkeit, die im phpmyadmin vorgesehen ist und nicht etwa, wie Arne Drews im anderen Thread schreibt, darauf zurückzuführen, daß "ThirdParty-Tools diese [Einstellung] sinnfrei überschreiben". Diese Einstellung zu ändern, kann in anderen Konstellationen helfen, wofür es hier im Forum auch bereits Beispiele gab.
                      Die ( sinnvollen ) Beispiele hätte ich gern mal gesehen, hast Du Links für mich?
                      Ganz ehrlich, es wird immer bemängelt, dass MySQL genau dieses Verhalten aufzeigt, fehlerhaft gruppierte Queries mit Resultaten zu beliefern. Jetzt, wo es gerade in Deine Argumentation passt, soll das wieder nur eine Option sein, die sogar in einigen Fällen hilfreich sein soll? Dann schlage ich als nächstes akretschmer vor, dass er das mal als CustomerVoice für Postgres einwirft, der wird sich freuen...

                      Und nur weil ThirdParty-Tools ( phpMyAdmin ist eins! ) die Möglichkeit bieten, es wieder zu deaktivieren, macht es das noch lange nicht zu einer nützlichen Einstellung, sorry.
                      Competence-Center -> Enjoy the Informatrix
                      PHProcks!Einsteiger freundliche TutorialsPreComposed Packages

                      Kommentar


                      • #56
                        Arne Drews , Du wirst lachen, *etwas* geht das sogar im PostgreSQL:

                        Code:
                        test=*# create table demo(a int primary key, b int);
                        CREATE TABLE
                        test=*# select a, max(b) from demo;
                        ERROR:  column "demo.a" must appear in the GROUP BY clause or be used in an aggregate function
                        LINE 1: select a, max(b) from demo;
                                       ^
                        test=*# select distinct on (a) a, b from demo order by a, b desc;
                         a | b
                        ---+---
                        (0 rows)
                        Quasi eine Alternative für max(), ohne group by ...
                        PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                        Kommentar


                        • #57
                          Denn ist ja doch noch etwas Licht am Ende des Tunnels für Postgres...
                          Competence-Center -> Enjoy the Informatrix
                          PHProcks!Einsteiger freundliche TutorialsPreComposed Packages

                          Kommentar


                          • #58
                            distinct on() ist cool - und nicht im SQL-Standard, sondern PostgreSQL-spezifisch. Ist so auch dokumentiert.
                            PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                            Kommentar


                            • #59
                              Zitat von Arne Drews Beitrag anzeigen
                              Die (sinnvollen) Beispiele hätte ich gern mal gesehen, ...Jetzt, wo es gerade in Deine Argumentation passt, soll das wieder nur eine Option sein, ...macht es das noch lange nicht zu einer nützlichen Einstellung, sorry.
                              Ließ dir bitte nochmal deinen Beitrag durch, langsam Wort für Wort. Und dann sag mir bitte, was dir auffällt. Insbesondere der 3. Satz, 1. Halbsatz.

                              Kommentar


                              • #60
                                Zitat von Arne Drews Beitrag anzeigen
                                Die ( sinnvollen ) Beispiele hätte ich gern mal gesehen, hast Du Links für mich?
                                Die MySQL Entwickler begründen das unter https://dev.mysql.com/doc/refman/5.7...-handling.html so:

                                Disabling ONLY_FULL_GROUP_BY is useful primarily when you know that, due to some property of the data, all values in each nonaggregated column not named in the GROUP BY are the same for each group.
                                sorry, shift-taste kaputt

                                Kommentar

                                Lädt...
                                X