Wie gesagt, die Hintergründe für deinen Ansatz leuchten mir schon ein. Aber schränkt ihr euch selbst damit nicht unheimlich ein? Da hat man ein so mächtiges Werkzeug wie
SQL, kann es aber nicht richtig nutzen, weil die Schnittstelle nach außen kein
SQL mehr unterstützt, sondern nur noch diese ziemlich kastrierte "Suchen"-Funktion z.B. Oder wie würdest du das realisieren, wenn ich jetzt innerhalb der Kundentabelle z.B. alle männlichen Kunden suchen will, deren Geburtsdatum zwischen 1960 und 1970 liegt, und alle weiblichen, deren Geburtsdatum zwischen 1970 und 1980 liegt? Wobei das ja noch eine ziemlich lächerliche Abfrage wäre, in der Praxis schaut das ja meist noch viel viel haariger aus. Das kannst du doch gar nicht so weit abstrahieren, um alle denkbaren und auch sinnvollen Möglichkeiten abzudecken
. Oder schlägst du tatsächlich vor, für jede Abfrage eine eigene Funktion zu implementieren???
EDIT: Und was ist, wenn irgendwann, wenn die Schnittstelle mal fertig ist und überall so eingebaut wurde, neue Suchkriterien hinzukommen, weil einfach die Anforderung dazu besteht? Wird dann jeweils eine neue Such-Funktion geschrieben, die eben die neuen Kriterien abdeckt oder wird gar die bestehende Suchfunktion angepasst und damit die ZIG Stellen, an denen sie mit den "alten" Parametern aufgerufen wurde? Ersterer Fall würde einen unheimlichen Wildwuchs an Funktionen erzeugen, die alle irgendwie dasselbe machen, in dem man irgendwann die Übersicht verliert. Letzterer Fall würde bewirken, dass sich die Schnittstelle ständig ändern würde und damit alle aufrufenden Funktionen gleich mit. Beides möchte ICH zumindest nicht verantworten müssen...