Ich verstehe die Frage jetzt irgend wie nicht... Du kannst doch in "begriff" in deinem 1. Beispiel alles möglich reinschreiben als String? Order irre ich da?
Wieso muss denn das "%" im Query-String stehen?!? Packe das doch in den Parameter rein! Damit bist Du auch viel flexibler... kann ja sein, dass man noch in der Mitte vom Suchbegriff ein "%" haben möchte
Außerdem solltest Du auf die Anzahl der "%" achten:
Interessant wäre trotzdem, ob dass der einzige (und Korrekte) weg ist...
EDIT: %%%s%% funktioniert nicht... IMHO deshalb, weil SQL das 1. und letzte % in Quotes haben will... IMHO kommt hier aber sowas wie %"begriff"% raus -> SQL-Error.
An sich ist das eine simple Lösung die gut funktionieren sollte.
Leider ist die like - suche relativ langsam, wenn ich das so sagen
darf.
Man könnte überlegen ob man eine Tabelle mit Suchwörtern verwaltet.
Grob angedacht, wird für jedes Suchwort, typischerweise Subjektive,
beim Insert/modify ermittelt und in der Suchtabelle mit Referenz auf
die ID gespeichert. Über die Suchwörter wird ein Index erstellt.
Da meistens nach subjektiven gesucht wird, könnte man hier eine
Leistungssteigerung beim Suchen erreichen, Ändern und Einfügen von
Datensätzen wäre aber natürlich langsamer.
Wobei die Auwahl der Suchbegriffe wohl nicht ganz trivial ist und ist
der Suchaufwand bei Begriffen die nicht in der Suchtabelle sind höher.
Ob der Lösungsansatz überhaupt Sinn macht hängt von der Detaillösung ab,
und so ist das vielleicht schon mit Kanonen auf Spatzen schießen.
Grüße Stefan
p.s. bei mir funktioniert die Lösung von hyperion (mit einer Postgres) auch
Konkret wird hier primär eine Spalte mit Feldlänge 500, Typ varchar durchsucht.
Ist in meinem Fall über überhaupt kein Performance-Problem, weil die Applikation im Intranet läuft und die DB so wie so weniger als 1 Query/Minute hat...