PHP / MySQL Such-Abfrage mit vielen Parametern

[Furtano]

Hi,

ich möchte in PHP/MySQL eine Suchabfrage für Autos mit ca. 30 Parametern machen wie PS, Anz. Türen usw. die alle kombiniert werden sollen.

Wie kann ich das am cleversten machen? Reinen MySQL Code zu schreiben wär sehr aufwändig / fehleranfällig.

Danke!

 

[derBobby]

Prepared Statements?

 

[Suxxess]

Ich würde verschiedene Tabellen nutzen und deine Autos bereits nach den Hauptkriterien einsortieren.

Sprich:
Automarke
Türanzahl
Diesel oder Benziner

Dann hast du halt jeweils eine Tabelle:
audi_5_benzin
vw_3_diesel

Und deine Kunden lässt du dann die Attribute in einem Dropdown Menu auswählen.
Wenn dein Kunde das richtig ausgewählt hat dann lässt du ihn nur in dieser speziellen Tabelle suchen.
Ergebnis: Eine Suche sucht nicht über den gesamten Datenbestand sondern jeweils nur in dieser Tabelle. Wenn jemand der ein Auto anbietet sein Auto reinstellen möchte, dann lässt du ihn ebenfalls die passende Tabelle über das Dropdown Menu aussuchen.

 

[derBobby]

@ Suxxess:

Wird das so in Unternehmen auch gemacht? Das kann ich mir gerade schwer vorstellen?

 

[Daaron]

The key, the whole key and nothing but the key, so help me Codd.
Das, was Suxxess hier beschreibt, verstößt gegen alle Regeln der Normalformen. So etwas sorgt nur für Redundanz und eigenartige Abhängigkeiten beim Löschen.

Es ist absolut kein Problem, ein PERFORMANTES Select-Statement über 30-40 Spalten zuschicken, wenn nur entsprechend ordentliche Indizes vergeben wurden.
Und was den Aufbau des Query angeht: einfach den Query-String Stück für Stück in Abhängigkeit der verschiedenen gewählten Parameter zusammenbauen.

 

[derBobby]

Danke Daaron, du hast meine Weltanschauung gerettet!

Was machst du eigentlich beruflich?

 

[Daaron]

Webentwickler, Fokus auf PHP. Wenn es nötig ist spiel ich auch die Pixelschubse.

 

[Suxxess]

Keine Angst ich mache nichts mit Datenbanken. Das mit der Normalisierung ist natürlich berechtigt.

Aber ist es wirklich performanter wenn du mit 20 Attributen über die gesamte Datenbank suchst als wenn du die Autos grob in einzelne Tabellen einsortierst und dann nur in den bereits vorselektierten Tabellen suchst?

Machen wir mal eine Tabelle Audi und eine Tabelle VW. Ist es wirklich performanter in einer Tabelle
z.B. nach Audi & 4 Türer zu suchen als in der Tabelle Audi nur nach 4 Türer? Was spricht denn dagegen nicht trotzdem die Normalisierung anzuwenden? Rein logisch hat man durch die Vorselektierung weniger Datensätze die überhaupt durchsucht werden müssten da z.B. alle Automarken die nicht Audi sind überhaupt nicht mit berücksichtigt werden würden.

 

[Daaron]

Wie schon gesagt: The key, the whole key and nothing but the key, so help me Codd!

Nach korrekter Normalisierung der Datenstrukturen (3. NF) gibt es nichts doppelt. Alles, was mehrmals vorkommt, wird auf einen eindeutigen Key reduziert. Du löst alle transitiven Abhängigkeiten.

So wie du es aufbauen würdest, hättest du sowohl in der Tabelle Audi als auch in der Tabelle VW jetzt einen Status "Viertürer", einen für "Diesel",... Deine beiden Tabellen wären um genau eine Spalte schlanker als deine verschmolzene Tabelle, nämlich um die Hersteller-ID. Beide Hersteller bauen 3-5 - Türer. Beide bieten Kompakt- bis Luxusklasse an. Beide vertreiben Diesel & Benzin in verschiedenen Hubraumgrößen....

Was du dir dabei aber schlichtweg versaust ist: "Liste mir alle Dreitürer mit >2l (respektive > 1990ccm, übliches Geschummel) Hubraum und > 120kW auf, unabhängig vom Hersteller". Diese Abfrage spuckt mir dann genauso einen Focus RS wie einen Golf GTI oder Scirocco aus. Nein, du müsstest jede Tabelle einzeln abfragen und am Ende die Ergebnismengen noch vereinen. Hochgradig ineffizient.

Also ja: "SELECT * FROM cars WHERE `class`='compact' AND `engine_size` > 1990 AND `engine_power` > 120" ist ein verdammt flotter Query, wenn nur Fahrzeugklasse, Hubraum, Motorleistung etc. jeweils einen Index haben. Sogar wenn man, wie man es sollte, den Hersteller jetzt nur als id listet, und dem entsprechend noch einen JOIN braucht um aus der Hersteller-ID auf den Namen des Herstellers zu schließen, ist es immer noch performant, vorausgesetzt auch die Hersteller-Liste hat anständige Indizes... wobei die ID eh der Primary Key ist, udn außerdem natürlich auch ein Foreign Key mit passenden Constraints