mehrere Abfragen, aber NUR WENN Sie auch da sind ;_)

[taisön]

Hallo, ich weis der Titel ist nicht der beste, aber ich habs versucht!

Ich habe eine grundsätzliche Frage in Bezug von einer Abfrage von einer Datenbank. Es gibt über ein Formular die Möglichkeit die Datenbank abzufragen. Hierbei kann man mehrere Textfelder benutzen aber auch mehrere SelectFelder. So dass es theoretisch sein kann das 14 Abfragen stattfinden.

Es wären aber theoretisch zig verschiedene Abfragen möglich. Da ja nicht jeder alle Felder ausfüllt.

Diese Abfragen möchte ich alle mittels einer SELECT Abfrage abfragen.

Feld…Name Feld…Jahreszahl Feld…Beruf Feld…Anzahl Etc…

Wenn jetzt z.b. nur das Feld Name, Jahreszahl und Beruf aktiviert wurden, muss ich ja nur eben diese 3 ausführen und kann die restlichen vergessen. Wie gehe ich dabei am elegantesten vor, so das ich nur die Abfragen stelle die auch gemacht werden.

AM einfachsten wäre es doch wenn ich die jeweiligen Abfragen in je eine Variable packe und dann einfach zu einer SELECT Abfrage zusammensetze. Doch wahrscheinlich ist das nicht die preisgekrönte Alternative

[Felix Riesterer]

Liebe(r) taisön,

Diese Abfragen möchte ich alle mittels einer SELECT Abfrage abfragen.

Feld…Name Feld…Jahreszahl Feld…Beruf Feld…Anzahl Etc…

Du wirst Dir eine passende Abfrage programmatisch zusammenstellen müssen. Sicherlich benutzt Du eine Script-Sprache (PHP? Du nennst mysqli...), mit der Du ausgehend von den ausgefüllten Feldern die benötigten Spalten ermitteln kannst, um eine maßgeschneiderte Abfrage zu formulieren.

Liebe Grüße,

Felix Riesterer.

[dedlfix]

Tach!

Wenn jetzt z.b. nur das Feld Name, Jahreszahl und Beruf aktiviert wurden, muss ich ja nur eben diese 3 ausführen und kann die restlichen vergessen. Wie gehe ich dabei am elegantesten vor, so das ich nur die Abfragen stelle die auch gemacht werden.

Ich würde einfach alle Felder abfragen und dann lediglich in der Ausgabe steuern, was angezeigt werden soll. Das ist deutlich einfacher, als das SQL-Statement imer wieder neu zu erstellen.

Wie? Es werden dann immer zu viel Daten abgefragt? Jein. Ich gehe mal davon aus, dass bei der Abfrage keine derartig große Datenmenge entsteht, als dass das ins Gewicht fällt.

dedlfix.

[Rolf B]

Hallo dedlfix,

alle Felder abfragen - wie denn? Zu viele Bedingungen im WHERE schränken das ergebnis ggf. zu sehr ein. Es sei denn, du arbeitest grundsätzlich mit LIKE und fragst bei unausgefüllten Kriterienfeldern nach "WHERE foo LIKE '%'". Aber ist das sinnvoll? Wenn ich nach 'dedlfix' suchen will, landet "WHERE foo LIKE 'dedlfix%'" in der Abfrage, und ich finde deinen großen Bruder dedlfixer.

Rolf

[dedlfix]

Tach!

alle Felder abfragen - wie denn? Zu viele Bedingungen im WHERE schränken das ergebnis ggf. zu sehr ein.

Geht es um die Where-Klausel? Ich dachte die Frage war auf die Feldauflistung im Select-Teil bezogen. Wenn das Selektionsbedingungen sind, dann ist es hingegen schon sinnvoll, sie nur bei Bedarf anzuführen. Am besten sammelt man die einzelnen Bedingungen in einem Array und implodiert das mit and. PHP-Pseudocode:

$where = [];
$values = [];

if (feld gewählt) {
  $where[] = 'feld=?';
  $values[] = suchwort;
}
...

$where = implode(' and ', $where);

Damit hat man den Where-Klausel-Teil für das Prepare und $values ist das Array für das Execute.

dedlfix.

[Rolf B]

Hallo dedlfix,

Geht es um die Where-Klausel?

Jupp, so hatte ich das verstanden.

$where[] = 'feld=?';

kann man tun. Taisön hat anderswo geschrieben, dass PDO verwendet wird. D.h. ggf. wäre eine benannte Variable geschickter. Das setzt dann eine Steuertabelle voraus, in der steht:

• POST-Name des Input-Elements (z.B. name)
• Name der Column (z.B. a_name)
• Name der SQL-Variablen (z.B. ':name')

Man kann dann über die Steuertabelle laufen und pro Eintrag gucken.

• existiert dieser Name in den POST-Daten
• wenn ja:
  • Erzeuge ein Fragment für die Where-Klausel. Hier: a_name = :name
  • Erzeuge eine Parameterbindung bzw. einen Array-Eintrag für den execute-Parameter.
    Hier: $queryData[':name'] = $_POST['name'].

Dieses Thema hatten wir schon in taisöns anderem Thread andiskutiert.

Rolf

[dedlfix]

Tach!

Taisön hat anderswo geschrieben, dass PDO verwendet wird. D.h. ggf. wäre eine benannte Variable geschickter.

Findest du? MySQL kann eh nur Fragezeichen, da muss PDO nicht übersetzen.

dedlfix.

[pl]

Wenn jetzt z.b. nur das Feld Name, Jahreszahl und Beruf aktiviert wurden, muss ich ja nur eben diese 3 ausführen und kann die restlichen vergessen. Wie gehe ich dabei am elegantesten vor, so das ich nur die Abfragen stelle die auch gemacht werden.

Die erste Überlegung wäre, ob es überhaupt einen Sinn macht, in einem Formular weitere Eingabelder vorzuhalten wenn sie serverseitig gar keine Rolle spielen.

Die zweite Überlegung wäre, falls die erste mit JA beantwortet wurde, wie das Ergebnis präsentiert werden soll.

Und die dritte Überlegung beträfe die serverseitige Logik, also wie da anhand der gesendeten Felder zu entscheiden ist welches Statement ausgeführt werden soll.

Willst Du da wirklich!? Wobei auch noch zu überlegen wäre, wie ein solches Monster dem Benutzer verständlich rübergebracht werden könnte.

Mein Tipp: Mach mehrere Formulare die im Einzelnen auch dem Anwender verständlich sind.

[Rolf B]

Hallo pl,

das ist letztlich ein generischer Filter, mit dem eine Table mit X Spalten nach (fast) jeder Spalte filtern kann. Für einen Excel-verwöhnten Bürohengst nichts Besonderes (für die Bürostuten auch nicht).

Die berechtigte Frage ist aber - ist das sinnvoll. Solange die Tabelle klein ist, sind solche Abfragen schnell. Wenn aber Volumen in der DB steckt, werden die meisten Abfragen dieser Art zu Table Scans führen, weil es garantiert nicht zu jeder Spalte einen Index geben wird. Hier führt die Excel-Denke in die Katastrophe, weil nämlich ein Web-Request nicht davon ausgehen kann, der einzige zu sein der auf der DB herumturnt.

Das heißt, taisön: Man KANN sowas bauen, indem man einfach eine Bedingung nach der anderen an's WHERE anklebt, aber SOLLTE man? Da müssen vorher Fragen geklärt sein:

• wieviele User sind unterwegs
• wie groß ist die abgefragte Table (wieviele Rows)?
• wie häufig werden solche Universalabfragen gemacht

Und wenn jetzt das Unbehagen anfängt zu grummeln, wäre die nächste Frage:

• Welche Abfragen werden wirklich gebraucht?
• Oder zumindest: Welche Abfragen sind häufig

Und für die muss man dann die Queries und ggf. die DB optimieren. Dies ist das Web. Kein Single-User PC. Es gibt ein Sprichwort: Das schlimmste, was einer Webanwendung passieren kann, ist Erfolg. Denn Erfolg bedeutet viele User. Und diejenigen, die mit Single-User Techniken gebaut wurden, knicken dann ein. Sobald die erste Query zu langsam ist, stauen sich die Abfragen. Und danach wird es nur noch schlimmer. Erfahrene Operatoren stellen eine Schüssel Mais auf den Server. Sobald das Popcorn fliegt, gibt es ein größeres Problem.

Rolf

[pl]

@Rolf B

Wieviele Eingabefelder sollen es denn werden!? Für 14 verschiedene Abfragen!? Und wie soll das Ergebnis aussehen, 14 verschiedene Ergebnisse, 14 verschiedene Templates, oder sieht das Ergebnis immer gleich aus!?

Darüber würde ich mal nachdenken. MfG

[Rolf B]

Hallo pl,

Und wie soll das Ergebnis aussehen, (...) Darüber würde ich mal nachdenken.

Das ist sicherlich bedenkenswert, aber die Frage zielte auf die Selektion, nicht die Präsentation. Bis zu einer gegenteiligen Aussage des OP würde ich das Problem daher ausblenden und annehmen, dass es um eine freie Filterung der Tabelle geht und die Präsentation immer gleich ist.

Rolf

[pl]

@Rolf B

also bei 14 verschiedenen Abfragen die aus einem Formular heraus generiert werden sollen, dürften die Überlegungen weniger programmiertechnischer sondern eher grundlegender Natur sein. Von der Benutzerfreundlichkeit einmal ganz abgesehen ist das in allererster Linie eine Frage der Herangehensweise.

MfG

[Rolf B]

Hallo pl,

das sind nicht 14 Abfragen (Abfrage im Sinne von einer Kombination möglicher Felder als Filterbedingung). Sondern $$\displaystyle\sum_{i=1}^{14} \binom{14}{i} = 2^{14}-1 = 16383$$

(-> Zeilensumme Pascalsches Dreieck)

Wie gesagt: Vom Konzept her ist das ein freier Anzeigefilter.

Rolf

[pl]

@Rolf B

Wie gesagt: Vom Konzept her ist das ein freier Anzeigefilter.

Genau das würde ich mal überdenken. Insbesondere hinsichtlich Benutzerfreundlichkeit. Vielleicht mit dem Gedanken im Hinterkopf daß Suchmaschinen (die jeder kennt!) nur ein Eingabefeld haben.

So könnte man dem Suchenden ja anbieten, daß er mehrere Suchbegriffe in ein Eingabfeld eingeben darf. Vielleicht sogar mit +name und -vorname was soviel heißt, daß name auf jeden Fall in den Treffern vorkommen muss, vorname hingegen nicht.

Das setzt natürlich ein paar Vorbereitungen voraus die serverseitig getroffen werden müssen. Z.B. einen Volltextindex.

MfG