Teil-Strings sowohl in Oracle als auch in SQL Server suchen?

[meute]

Hallo,

ich bin auf der Suche nach einer Möglichkeit ein identisches SQL-Statement sowohl bei Oracle als auch bei SQL Server zu verwenden.

Problem:
Ein User hat auf einer Software-Oberfläche ein Eingabefeld zur Verfügung welches als Variable in einer dahinterliegenden WHERE-Bedingung verwendet wird.

Wenn er auf [Suche] klickt, wird im Hintergrund ein SQL-Statement abgearbeitet und dem User das Ergebnis präsentiert.
Damit er Teil-Strings suchen kann, habe ich in der WHERE-Bedingung die Variable mit % und || am Anfang und Ende verkettet.
Das ?-Zeichen in der WHERE-Bedingung ist die Variable, die mit dem Text aus dem Eingabefeld des Users gefüllt wird.
In Oracle funzt das auch tadellos.

Beispiel:

select A.ID
  from TABELLE A
where (upper(A.ID) like upper('%'||?||'%'))
order by A.ID asc
;

Aber SQL Server kann die Verkettung || nicht auswerten. Dort müsste es ein +-Zeichen sein.
Auch "concat" funzt bei SQL Server nicht.

Kann man die WHERE-Bedingung irgendwie umbauen, damit man ohne die Verkettungszeichen nach Teil-Strings suchen kann?

Danke.


Gruß
meute

[dimitri]

Hi,

hast Du schon mal versucht, die % schon im Programm hinzuzufügen und dann den fertigen String zu binden?

Also was in der Richtung:

searchString='%'+searchString+'%';
pstmt.setString(1,searchString);

Dim

PS: Dir ist klar, dass mit dieser Art der Suche keine Datenbank der Welt einen evtl. vorhandenen Index verwenden wird? Bei größeren Tabellen könnte das problematisch werden.

[meute]

Hallo,

Hi,
hast Du schon mal versucht, die % schon im Programm hinzuzufügen und dann den fertigen String zu binden?

Also was in der Richtung:

searchString='%'+searchString+'%';
pstmt.setString(1,searchString);

Das wäre vll. einen Versuch wert.
Da muss ich mal den Hersteller der Software kontakten, wo das versteckt ist.
Nur würden dann halt alle Suchen der Software so arbeiten, auch die Suche nach Zahlen.

PS: Dir ist klar, dass mit dieser Art der Suche keine Datenbank der Welt einen evtl. vorhandenen Index verwenden wird?

Nö, kannst Du kurz erkären warum nicht?

Entweder gibt der User das % mit ein, weil er nie den genauen Text im Feld wissen kann oder ich definiere es fest vor.
Da dürfte doch kein Unterschied sein?


Gruß
meute

[dimitri]

Entweder gibt der User das % mit ein, weil er nie den genauen Text im Feld wissen kann oder ich definiere es fest vor.

Es ist egal wer das % eingiebt. Bei einem LIKE '%abc' kann die DB keinen index verwenden. Wo sollte sie denn anfangen zu suchen? Stell dir einen Index wie ein Stichwortverzeichnis in einem Lexikon vor. Jetzt bekommst Du die Aufgabe, nach Wörtern zu suchen, die abc beinhalten. Das kann theoretisch überall und nirgends sein. daher ist das Stichwortverzeichnis für dich sinnlos.

Da das Suchen über den index nur für relativ kleine Datenmengen effektiv ist (ein indexzugriff ist nicht immer schneller als ein Full Tablescan, auch wenn das oft geglaubt wird) wird die Datenbank daher die komplette Tabelle durchsuchen.

nur würden dann halt alle Suchen der Software so arbeiten, auch die Suche nach Zahlen.

Wenn die betreffende Spalte in der DB nummerisch ist, wird nie ein index verwendet, denn wenn Du auf ein nummerisches Feld WHERE col LIKE '...' machst, wird die DB das nummerische Feld implizit in einen String casten. Da ein String jedoch eine andere Sortierreihenfolge hat wie eine Zahl, ist der Index wiederum nutzlos. Du bräuchtest dazu einen funktionsbasierten Index.

Für das durchsuchen von Texten gibt es übrigends Volltextindices, die genau dafür vorgesehen sind. Allerdings wird dazu nicht LIKE verwendet, sondern ein DB anhängiges Schlüsselwort.

Um das ganze wirklich datenbankunabhängig zu machen, müsstest Du für beide Datenbanken eine Stored Function schreiben, die als Parameter den Suchbegriff bekommt und einen Cursor (=Result Set) zurückliefert. Unter Oracle läßt sich das mit einem REF CURSOR verwirklichen - wie das unter MSSQL geht weiß ich nicht.

Dim