trunx: mysql - zwei Suchkriterien unterschiedlicher Priorität

Hallo Forum,

ich möchte gern folgendes in einer SQL-Abfrage realisieren (und nicht wie bisher in zweien, verknüpft durch php):
Abfrage 1:
SELECT MIN(ID) FROM tabelle WHERE kriterium1 != ""
Wenn nun ein leeres Ergebnis zurückgegeben wird, starte ich die
Abfrage 2:
SELECT MIN(ID) FROM tabelle WHERE kriterium2 != ""

D.h. ein Datensatz, der Kriterium 1 erfüllt, aber eine höhere ID hat, hat dennoch eine höhere Priorität als ein Datensatz mit niedriger ID, der aber nur Kriterium 2 erfüllt.

Wie immer wär's wundervoll, wenn wer was weiß...

ciao trunx

--
Die Standard-Antwort: "Bitte benutze die Forum-Suche!" macht die Forum-Suche kaputt, weil die Suche dann nämlich genau vor allem diese dämliche Standard-Antwort, also Müll liefert. Sinnvoller ist stattdessen folgende Standard-Antwort: "Dieses Thema wurde schon vielfach im Forum besprochen, siehe z.B. <a>hier</a> oder <a>da</a> oder benutze die Forum-Suche z.B. mit den Stichworten 'Stichwort1 Stichwort2'." Danke.
  1. Tach!

    Abfrage 1:
    [...]
    Wenn nun ein leeres Ergebnis zurückgegeben wird, starte ich die

    Ein "Wenn" mit kompletten Abfragen gibt es nur mit Stored Procedures.

    D.h. ein Datensatz, der Kriterium 1 erfüllt, aber eine höhere ID hat, hat dennoch eine höhere Priorität als ein Datensatz mit niedriger ID, der aber nur Kriterium 2 erfüllt.

    (Numerische) IDs haben in den meisten Fällen keine Bedeutung. Wenn du eine (einfüge)zeitliche Priorisierung haben willst, dann nimm ein Zeit-Feld. Ansonsten auch wieder der Hinweis: Logik gibt es mit Stored Procedures.

    dedlfix.

    1. moin,

      Wenn nun ein leeres Ergebnis zurückgegeben wird, starte ich die

      Ein "Wenn" mit kompletten Abfragen gibt es nur mit Stored Procedures.

      muss ich mir mal ansehen...

      (Numerische) IDs haben in den meisten Fällen keine Bedeutung. Wenn du eine (einfüge)zeitliche Priorisierung haben willst, dann nimm ein Zeit-Feld. Ansonsten auch wieder der Hinweis: Logik gibt es mit Stored Procedures.

      die ID im Beispiel ist sicher sinnfrei, auch die ganze Abfragerei ist in der Realität natürlich komplexer. Es geht beim MIN() nicht um die Einsortier-Reihenfolge, sondern lediglich um die Auswahl eines beispielhaften Eintrags aus einer Vielzahl von Sätzen mit derselben Kennnummer (sprich MAX() hätte ich auch nehmen können oder sonst irgendwas, was aus einer Menge ein Element auswählt).

      ciao trunx

      --
      Die Standard-Antwort: "Bitte benutze die Forum-Suche!" macht die Forum-Suche kaputt, weil die Suche dann nämlich genau vor allem diese dämliche Standard-Antwort, also Müll liefert. Sinnvoller ist stattdessen folgende Standard-Antwort: "Dieses Thema wurde schon vielfach im Forum besprochen, siehe z.B. <a>hier</a> oder <a>da</a> oder benutze die Forum-Suche z.B. mit den Stichworten 'Stichwort1 Stichwort2'." Danke.
      1. Ein "Wenn" mit kompletten Abfragen gibt es nur mit Stored Procedures.

        muss ich mir mal ansehen...

        das ist nun passiert, meine Güte, das schaff ich heute nicht mehr zu lernen...
        aber ok, erstmal danke :)
        wie ist denn die Performance von solchen Procedures? Also "lohnt" sich die Verlagerung von php ins mysql?

        ciao trunx

        --
        Die Standard-Antwort: "Bitte benutze die Forum-Suche!" macht die Forum-Suche kaputt, weil die Suche dann nämlich genau vor allem diese dämliche Standard-Antwort, also Müll liefert. Sinnvoller ist stattdessen folgende Standard-Antwort: "Dieses Thema wurde schon vielfach im Forum besprochen, siehe z.B. <a>hier</a> oder <a>da</a> oder benutze die Forum-Suche z.B. mit den Stichworten 'Stichwort1 Stichwort2'." Danke.
        1. Tach!

          wie ist denn die Performance von solchen Procedures? Also "lohnt" sich die Verlagerung von php ins mysql?

          Die Performance-Frage hab ich mir noch nicht gestellt. Ob sie überhaupt wichtig ist, kann nur unter Kenntnis der Rahmenbedingungen beantwortet werden. Viel wichtiger ist die Wartbarkeit des Gesamtprodukts. Wenn die Performance bei Berechnungen lahmt, kann man mit Prozessorpower meist günstiger Abhilfe schaffen als beim Entwickler, der wegen der Komplexität mehr Zeit braucht.

          dedlfix.

          1. Moin!

            Tach!

            wie ist denn die Performance von solchen Procedures? Also "lohnt" sich die Verlagerung von php ins mysql?

            Die Performance-Frage hab ich mir noch nicht gestellt. Ob sie überhaupt wichtig ist, kann nur unter Kenntnis der Rahmenbedingungen beantwortet werden. Viel wichtiger ist die Wartbarkeit des Gesamtprodukts. Wenn die Performance bei Berechnungen lahmt, kann man mit Prozessorpower meist günstiger Abhilfe schaffen als beim Entwickler, der wegen der Komplexität mehr Zeit braucht.

            An dieser Stelle sind Stored Procedures allerdings durchaus kritisch zu betrachten, denn sie sind fraglos ausführbarer Code, das heißt, Fragen wie Deployment, Versionskontrolle, Bundling mit der restlichen Software, Testing, Backup etc. sind zu klären. Das kann die Sache recht komplex machen.

            Einfach nur mit PHPMyAdmin was in die DB reinfriemeln erfüllt die Kriterien sicher nicht.

            - Sven Rautenberg

  2. Hallo, in Abhängigkeit von der Komplexität deiner Abfragekriterien kann man dies auch in einer Abfrage machen, in dem man mittels CASE WHEN THEN ELSE END die Kriterien abarbeitet und entsprechend "Punkte" verteilt, so à la

    CASE
     WHEN (KRITERIUM1) THEN 10
     WHEN (KRITERIUM2) THEN 5
     ELSE 0
    END

    Geschachelt in eine Unterabfrage, brauchst du danach nur noch ein LIMIT 1,1 ORDER BY "dein berechnetes Feld" DESC

    BTW .. bei den Datenbanksystemen mit denen ich arbeite ist eine Begrenzung (mit Sortierung) der Ergebnismenge (TOP 1, LIMIT 1,1) einer Aggregation (MIN/MAX) in den meisten Fällen vorzuziehen.

    Ciao, Frank