SQL-Abfragen in Radio-Buttons/Check-Boxen integrieren

[queensophia]

Hallo Leute,


ich habe gerade mit der PHP-Programmierung angefangen und stehe vor folgender Aufgabe.

Und zwar möchte ich SQL-Select-Abfragen in Radio-Buttons und Checkboxen integrieren.

Sprich, je nachdem wie ich die Häkchen / Button setze, sollen bestimmte Ergebnisse aus der Datenbank aufgerufen werden.

Ich habe leider keine guten Tutorials dazu gefunden, was aber wahrscheinlich daran liegt, dass ich die falschen Suchbegriffe verwendet habe. Daher die Bitte, könntet ihr gleich sagen, wonach ich suchen muss, damit ich diese Thematik finde?

Besten Dank für eure Hilfe!

Im Folgenden habe ich das ganze nochmal visualisiert:

 

[Fragenfrager]

Die Buttons stammen aus einem Formular. Somit könnest Du die Ergebnisse des Formulars abfangen und dann entsprechend Dein Statement zusammenbauen.
Ich gehe davon aus, dass die Grundabfrage gleich bleibt und sich nur die WHERE-Klausel ändert.

$stmt="SELECT feld1,feld2 FROM Tabelle WHERE 1=1"; //1=1, damit wir problemlos die anderen Bedingungen mit "AND .." anhängen können.
// Formulardaten abfangen
if (isset($_POST['nationalitaet'])){
   $nat=$_POST['nationalitaet']']
   $stmt=$stmt+" AND natio=$nat";
}

// für die anderen Felder analog

Für die Checkboxen musst Du ggf mit SWITCH-CASE arbeiten, aber der Aufbau ist identisch:
Nimm Dein Grundstatement und hänge dann immer ein "AND ..." an, wenn die entsprechende Bedingung erfüllt ist.
Wenn Du das Ergebnis immer "Live" angezeigt haben willst, musst Du im Formular mit Javascript und "onChange()" arbeiten. In dem Fall solltest Du dann auch mit selected='selected' arbeiten, um Deine User nicht zu verwirren.
Vielleicht gibt es auch elegantere Lösungen, aber das wär (m)ein Ansatz.

 

[Sprint]

Abgesehen davon, daß die im Formular übermittelten Werte noch validiert werden sollten, ist der Ansatz von @Fragenfrager absolut richtig.

Dem schematischen Aufbau nach denke ich aber auch, daß hier eine Live Suche angedacht ist. Da solltest du dich mal mit der Datenbankabfrage mittels Ajax beschäftigen, am einfachsten in Verbindung mit jQuery. Da wird es wirklich so einfach, daß selbst ich es schnell hinbekommen habe.Versuch es bei Google mal mit "Ajax live Datenbank" oder so. Aber auch in der dann verwendeten PHP Datei, die über Ajax angesprochen wird, sieht die Abfrage im Prinzip so aus wie oben aufgeführt.

 

[queensophia]

Super vielen Dank Jungs.
Ich versuche das aus

 

[mermshaus]

Ich würde die Frage nach der Livesuche aber ruhig erst mal ausklammern, weil sie auf den Zusammenbau der Query im PHP-Teil keinen Einfluss hat. Du kannst das Formular auch erst mal ganz klassisch abschicken, ohne AJAX zu verwenden. Das macht es sicherlich einfacher. Das sind verschiedene Arbeitsschritte.

Den Workaround mit WHERE 1=1 kann man sich sparen. Das geht mit ca. einer if-Abfrage (auf PHP-Ebene) eleganter. Ich würde zudem die einzelnen Teilbedingungen erst in ein Array eintragen und dann per implode(' AND ', $conditions) verbinden.

Für Mehrfachauswahlen (die Essenskategorien und die Stadtteile) muss in der Teilbedingung noch mal mit OR oder mit IN gearbeitet werden.

Wobei das alles etwas leichter gesagt als getan ist, da allein an der Abfrage, wie sie in der Grafik in #1 skizziert ist, mindestens vier relationale Entitäten beteiligt sind (Restaurant, Cuisine, FoodType, District). Anders gesagt: Das sind schon mal vier Tabellen. Dazu noch die Zuordnungstabellen für Many-to-many-Relationen zwischen den Entitäten (ein Restaurant kann mehrere „Küchen“ (Cuisine) anbieten, eine Küche wird von mehreren Restaurants angeboten → many-to-many).

Das erfordert schon so einige JOINs, um in der Abfrage erst mal alle Daten zueinander in Beziehung zu setzen.

Außerdem ergibt es vielleicht nicht so ganz viel Sinn, etwa Chinesische Küche und dazu Calzone auswählen zu können, weil das Gericht in der Küche nicht vorkommen dürfte. Das wären für derlei Kombinationen dann immer 0 Suchtreffer. Das Formular müsste mehrschrittig aufgebaut sein oder die Suche müsste auf OR basiert werden statt auf AND. Wobei OR auch nicht viel Sinn ergibt, da die einzelnen Kategorien dann nicht stärker filtern/die Ergebnismenge weiter einschränken.

Das ist keine so ganz triviale Aufgabe. Die Konzeption des Datenbankschemas ist bereits schwierig.

 

[Sprint]

Generell hat @mermshaus schon recht. Einfach wird die Sache mit Sicherheit nicht.

Wobei ich dann aber die Live Suche per Ajax schon wieder ins Spiel bringen würde. Denn dann könnte man die Abfrage in mehrere Stufen auftrennen und von oben nach unten abarbeiten. Wobei das auch insofern benutzerfreundlicher wäre, da man nicht das ganze Formular ausfüllen muß, wenn schon nach ein oder zwei Stufen keine Treffer mehr da sind.

 

[mermshaus]

Ja, aus UI-Sicht ergibt das sicherlich Sinn. Ich wollte auch nicht sagen, dass man die JS/AJAX-Sache ganz lassen sollte. Mir ging es einfach erst mal darum, dass die Umsetzung im User Interface auf die Generierung der SQL-Query im Backend keinen nennenswerten Einfluss hat. Die Parameter kommen aus PHP-Sicht so oder so per HTTP-Request rein. Mit AJAX hat man halt noch die zusätzliche Erschwernis (so richtig schwierig ist die reine Client-/Server-Kommunikation im Verhältnis nicht, wenn man ein wenig weiß, was man tut, da stimme ich zu – die UI-Aktualisierung schon mehr), dass man noch in einer zusätzlichen Sprache programmieren muss. Für den PHP-Teil ist es nicht so wichtig. Einmal generiert man dort direkt HTML, einmal generiert man dort nur die Daten als JSON, um sie als so eine Art API an die Seite zurückzuliefern. Das gibt sich nicht viel. Der schwierige Teil ist meines Erachtens erst mal das Datenbankschema und dann das Generieren der SQL-Query/-Queries.

Mein Gedanke dahinter ist letztlich der, nicht alles auf einmal oder zumindest parallel machen zu müssen, weil es dann vielleicht doch etwas zu viel Input und eine zu große Baustelle wird. Dabei nehme ich aber in Kauf, dass vielleicht ein wenig Refactoring notwendig sein wird, wenn man dann auf eine AJAX-Basis umstellt, ja. Der Query-Generator in PHP sollte aber so geschrieben sein, dass er mit „beliebigen“ Eingaben umgehen kann. Wobei es natürlich erlaubt ist, unsinnige Eingaben zurückzuweisen.

Ich bin mir zudem nicht so ganz sicher, dass die Aufsplittung in „Cuisine“/Küche und „FoodType“/Essenskategorie (Pizza, Pasta, Feuertopf, …) so ganz geschickt ist. Ich kann aber nicht mit dem Finger drauf zeigen. Einerseits fasst die Cuisine eine Gruppe von Essenskategorien zusammen, andererseits wird es wohl in vielen Küchen eine Gruppe „Suppe“ oder „Salat“ geben können. Außerdem wären auch Suchanfragen nach „Chinesisch ODER Pizza“ denkbar. Das ist wohl letztlich eine Designfrage, die ein wenig knifflig zu evaluieren ist.