Tach!
Mach doch eine Abfrage und stelle für diese die Bedingungen zusammen anstatt für jede Bedingung eine eigene Abfrage zu erstellen.
Das wollte ich anfangs auch tun, doch war der Zusammenbau des SELECT-Teils mein gedankliches Problem. Wie ist es hier möglich, die vorkommenden Auswahlkombinationen (einzelne Spalten (nicht) durchsuchen) _ohne_ alle einzelnen Möglichkeiten (wie per vorgelagerter Abfrage usw.) explizit beschrieben zu bedienen, zumal ja auch das Auftauchen des jeweils ersten OR "geplant" werden muss. An anderen Stellen habe ich ebendies genutzt, doch dürfte der Aufwand zukünftig hinzukommender Spalten und deren Abfragemöglichkeit entsprechend viele neue Kombinationsdefinitionen nach sich ziehen ...
So wie ich das verstehe, hast du eine Reihe Bedingungen und der Anwender sagt, welche davon genommen werden sollen. Letztlich weißt du nicht, wieviele das werden, musst aber flexibel die WHERE-Teile erstellen. Geh doch so vor: Erstelle zunächst ein leeres Array. Dann geh durch alle Eingaben durch und füge dem Array die gewählten Teilbedingungen zu und zwar ohne Verknüpfungen zwischen ihnen. Am Ende hat das Array beliebig viele Einträge, welche du mit implode() und einem " OR " als Leim zu einer Gesamtbedingung zusammenfügen kannst.
Konkret ist es so: Gleich nach dem Formularcode baue ich die Verbindung zur DB auf und wende mysql_real_escape_string noch vor den anderen Abfragen (Mindestspaltenwahl u.ä.) an; nach diesem Kontrollblock folgen dann die angeführten if-Abfragen. Lässt sich dies tatsächlich durch eine mql_real_escape_string-Verlegung optimieren?
Es ist ungünstig, wenn du die Maskierung zu den Originaldaten hinzufügst. Diese sind dann für weitere Verwendungen außer dem SQL-Statement gestorben, ohne dass du die Maskierung wieder rückgängig machst. Es ist besser, die Werte in ihrer Rohform zu lassen und nur bei Bedarf die Maskierung direkt beim Einfügen in den jeweiligen Kontext vorzunehmen.
dedlfix.