# Umgekehrte Suche mit Wildcards



## ARadauer (18. Jun 2012)

Wir haben die Anforderung für eine umgekehrte Wildcardsuche in unserer Anwendung.

also zb in der Datenbank steht:
Code Rabatt
1_34 5%
2_34 6%
123_ 7%

Grundsätzlich ist das ja kein Problem...

select rabatt from rabatte where '123456' like concat(code,'%') order by code
liefert mir an erster stelle den gewünschten Eintrag.

Ich bin aber noch nicht ganz zufrieden, da ja der Benutzer eher die Wildcards * und ? kennt. Ich würd gerne automatisch beim inserten und updaten ? mit _ und * mit % ersetzen und beim lesen genau umgekehrt.

Kann ich das mit Hibernate irgendwie machen? Oder habt ihr andere Ideen?


----------



## mla.rue (18. Jun 2012)

du sagst doch selbst "unsere Anwendung"... wo steht geschrieben, dass in der Datenbank das ankommen muss, was der Benutzer in der Anwendung eintippt?


----------



## SlaterB (18. Jun 2012)

technisches Gemecker:
wieso steht noch die Rabatt-Spalte mit 5% usw. in den Beispielen zur DB?
wenn es um concat(%) und 123456 geht, ist ein irrelevantes 5% direkt hinter 1_34 extrem verwirrend, 

deine Frage wäre mit

```
also zb in der Datenbank steht:
Code 
1_34 
2_34 
123_
```
viel deutlicher..

------

naheliegend könnte 1?34 in der DB gespeichert und vor dem LIKE noch ersetzt werden,
ob das LIKE dann funktioniert kann ich nicht sagen, selber schon getestet?
oder kommt die Idee nicht in Frage, nichts zu gesagt bisher, ist ja keine weit hergeholte Idee (sondern naheliegend   )


----------



## ARadauer (18. Jun 2012)

SlaterB hat gesagt.:


> deine Frage wäre mit
> ...viel deutlicher..



stimmt... ich stell aber halt auch selten fragen, das kann ich nicht so gut :toll:
------



SlaterB hat gesagt.:


> naheliegend könnte 1?34 in der DB gespeichert und vor dem LIKE noch ersetzt werden,



ich weiß icht, macht mir dann der index nicht probleme? wird dass dann nicht automatisch ein full table scan?

und ausserdem müsste ich beim order auch nochmal ersetzen, da das ? zwischen den zahlen und buchstaben bei der sortierung ist..


----------



## SlaterB (18. Jun 2012)

warum sollte es bisher kein 'full table scan' sein? 
wie ich mir das unbedarft vorstelle muss doch für jeden Eintrag erst concat ausgeführt 
und dann vor allem das LIKE in all seinen Nöten ausgerechnet werden,
was könnte da bisher gespart sein?

zum Order:
sind Buchstaben beteiligt? 
das _ ist doch bisher reichlich zufällig vor oder nach den Zahlen, 
wenn du mit Glück bisher deine Sortierung danach richten konntest, nun gut, dann verlierst du in der Hinsicht etwas


----------

