Jan W: MySQL: order by - Verständnisproblem

Hallo!

Ich möchte das Ergebnis einer einfachen Datenbankabfrage sortieren, erhalte aber nicht das von mir erwartete Ergebnis:

SELECT eventname FROM EVENTS ORDER BY presented DESC, recommended DESC, calendardate

presented -> vom Typ tinyint (mögliche Werte 0 und 1) recommended -> vom Typ tinyint (mögliche Werte 0 und 1) calendardate -> vom Typ datetime

Meiner Meinung nach müssten jetzt alle Events so sortiert rauskommen: zuerst die, bei denen eine '1' bei 'presented' eingetragen ist, danach die, bei denen 'recommended' auf '1' gesetzt ist und danach die, bei denen 'presented' und 'recommended' eine '0' beinhalten. Diese dann aufsteigend nach Datum sortiert.

Bei meinen aktuellen Daten, habe ich kein Event, wo 'presented' auf '1' steht, 3 Datensätze, wo 'recommended' auf '1' steht und viele weitere, bei denen keines der beiden Felder auf '1' steht.

Somit gehe ich davon aus, dass zuerst die drei Datensätze rauskommen, bei denen 'recommended' auf '1' steht, sortiert nach Datum aufsteigend und dann alle anderen Datensätze, auch sortiert nach Datum aufsteigend.

Nun erhalte ich aber z.B. zuerst ein Event, welches in 'presented' und 'recommended' eine '0' enthält, aber das Datum am kleinsten ist. Danach kommen einige andere und irgendwann kommen die, bei denen 'recommended' auf '1' steht.

Wo ist mein Denkfehler?

Danke!

  1. Hallo und guten Morgen,

    SELECT eventname FROM EVENTS ORDER BY presented DESC, recommended DESC, calendardate
    

    presented -> vom Typ tinyint (mögliche Werte 0 und 1) recommended -> vom Typ tinyint (mögliche Werte 0 und 1) calendardate -> vom Typ datetime

    Meiner Meinung nach müssten jetzt alle Events so sortiert rauskommen: zuerst die, bei denen eine '1' bei 'presented' eingetragen ist, danach die, bei denen 'recommended' auf '1' gesetzt ist und danach die, bei denen 'presented' und 'recommended' eine '0' beinhalten. Diese dann aufsteigend nach Datum sortiert.

    Bei meinen aktuellen Daten, habe ich kein Event, wo 'presented' auf '1' steht, 3 Datensätze, wo 'recommended' auf '1' steht und viele weitere, bei denen keines der beiden Felder auf '1' steht.

    Somit gehe ich davon aus, dass zuerst die drei Datensätze rauskommen, bei denen 'recommended' auf '1' steht, sortiert nach Datum aufsteigend und dann alle anderen Datensätze, auch sortiert nach Datum aufsteigend.

    Nun erhalte ich aber z.B. zuerst ein Event, welches in 'presented' und 'recommended' eine '0' enthält, aber das Datum am kleinsten ist. Danach kommen einige andere und irgendwann kommen die, bei denen 'recommended' auf '1' steht.

    ist NULL erlaubt?

    Zeig mal bite das Create-Statement der Tabelle.

    Grüße
    TS

    --
    es wachse der Freifunk
    http://freifunk-oberharz.de
    1. ist NULL erlaubt?

      Zeig mal bite das Create-Statement der Tabelle.

      CREATE TABLE `EVENTS` (
        `id` int(11) NOT NULL AUTO_INCREMENT,
        `calendardate` date NOT NULL DEFAULT '0000-00-00',
        `eventname` varchar(255) DEFAULT NULL,
        `recommended` tinyint(1) NOT NULL DEFAULT '0',
        `presented` tinyint(11) DEFAULT NULL,
        PRIMARY KEY (`id`),
        KEY `calendardate` (`calendardate`) USING BTREE,
        KEY `eventname` (`eventname`)
      ) ENGINE=MyISAM AUTO_INCREMENT=60111 DEFAULT CHARSET=latin1;
      

      'presented' und 'recommended' wurde zeitlich später und auch jeweils zu unterschiedlichen Zeiten hinzugefügt.

      Sollte ich die beiden Spalten gleich definieren? Also beide bspw. mit "NOT NULL DEFAULT '0'"?

      1. Hey,

        presented tinyint(11) DEFAULT NULL,

        Etwas viele Stellen für tiny ;)

        Gruß
        Jo

        1. presented tinyint(11) DEFAULT NULL,

          Etwas viele Stellen für tiny ;)

          Hm, habe ich eben, als ich das Create-Statement rausgesucht habe, auch gesehen. Man sollte im Jahresabstand immer mal auf seine Tabellen schauen, um alte Dummheiten zu beseitigen :)

          1. Hey,

            presented tinyint(11) DEFAULT NULL,

            Etwas viele Stellen für tiny ;)

            Hm, habe ich eben, als ich das Create-Statement rausgesucht habe, auch gesehen. Man sollte im Jahresabstand immer mal auf seine Tabellen schauen, um alte Dummheiten zu beseitigen :)

            Das hat wohl nichts mit Dummheit zutun, eine kleine Unkonzentriertheit und schon steht da eine 1 mehr. Ist sicher jedem schon passiert.

            Gruß
            Jo

        2. Hallo und guten Morgen,

          presented tinyint(11) DEFAULT NULL,

          Etwas viele Stellen für tiny ;)

          Das Problem steckt in dem DEFAULT NULL.

          NULList weder 0 noch 1. Da müsste bei der Abfrage mit Is Not Null darauf Rücksicht genommen werden.

          Außerdem sind Sortierungen und Indexe über (quasi-) logische (boolesche) Felder ungünstig. Das verhindert schnelles Finden im Index.

          Grüße
          TS

          --
          es wachse der Freifunk
          http://freifunk-oberharz.de
          1. Hallo und guten Morgen,

            presented tinyint(11) DEFAULT NULL,

            Etwas viele Stellen für tiny ;)

            Das Problem steckt in dem DEFAULT NULL.

            NULList weder 0 noch 1. Da müsste bei der Abfrage mit Is Not Null darauf Rücksicht genommen werden.

            Ok, vielen Dank. Ich werde das mal bereinigen und dann mal schauen!

            Eine schöne Woche allen hier!

            PS: Läuft jetzt wie gewünscht! :)

          2. Tach!

            NULList weder 0 noch 1. Da müsste bei der Abfrage mit Is Not Null darauf Rücksicht genommen werden.

            Nö, nicht in dem Fall. Für das Sortieren von positiven Integer-Zahlen verhält es sich ohne weiteres Zutun quasi wie -1.

            When doing an ORDER BY, NULL values are presented first if you do ORDER BY ... ASC and last if you do ORDER BY ... DESC.

            dedlfix.

        3. Tach!

          presented tinyint(11) DEFAULT NULL,

          Etwas viele Stellen für tiny ;)

          Ist aber irrelevant, sowohl für die Daten als auch für das aktuelle Problem. Ich wüsste jetzt auch grad nicht, an welcher Stelle eine solche Angabe für Integer-Werte ausgewertet wird. Der Speicherverbrauch richtet sich nach dem Typ an sich. Beim Zugriff über die API bekommt man den Wert ohne Formatierung, selbst an der Konsole richtet sich die Spaltengröße nach dem eigentlichen Wert.

          dedlfix.

          1. Hallo und guten Tag,

            Ist aber irrelevant, sowohl für die Daten als auch für das aktuelle Problem. Ich wüsste jetzt auch grad nicht, an welcher Stelle eine solche Angabe für Integer-Werte ausgewertet wird. Der Speicherverbrauch richtet sich nach dem Typ an sich. Beim Zugriff über die API bekommt man den Wert ohne Formatierung, selbst an der Konsole richtet sich die Spaltengröße nach dem eigentlichen Wert.

            Das ist nur für Autoforms interessant. Da ist dann plötzlich das Eingabefeld zu groß oder zu klein. Aber damit ist MySQL ja nicht wirklich weiter gekommen bisher.

            Grüße
            TS

            --
            es wachse der Freifunk
            http://freifunk-oberharz.de