WHERE über alle Felder

[Angel4585]

Hallo zusammen,

wie kann ich eine WHERE Klausel über alle Felder machen ohne jedes Einzelne anzugeben?

Also sowas wie

SQL-Code:

SELECT * FROM Tabelle
WHERE * LIKE "%Suchbegriff%"

leider funktioniert dies so nicht. Weis jemand wie ich das schaffe?

MfG Angel4585

[Sharky]

Zitat:

Zitat von Angel4585

... Weis jemand wie ich das schaffe? ...

Hai Angel4585,

ich fürchte das es nicht gehen wird. Du musst schon die Felder angeben.

[Angel4585]

hmm.. OK.. aber die Frage wars Wert... THX Sharky :dp:

:angel:


MÖÖÖPPP

Wie sieht dann das Statement aus?

SQL-Code:

SELECT * FROM Tabelle 
WHERE Feld1,Feld2,Feld3,..,Feldn LIKE "%Suchbegriff%"

scheint nicht zu gehen.

Muss ich den Suchbegriff etwas für jedes Feld extra angeben??
:shock:

Also so:

SQL-Code:

SELECT * FROM Tabelle 
WHERE (Feld1 LIKE "%Suchbegriff%")OR(Feld2 LIKE "%Suchbegriff%")

?!?! :shock:

Also meine Version ist da etwas kürzer :stupid: , oder kann ich das doch irgendwie abkürzen? :gruebel:

[mkinzler]

Zitat:

Muss ich den Suchbegriff etwas für jedes Feld extra angeben??

Ja!

[jim_raynor]

Ich weiß nicht ob es performanter ist aber bestimmt kürzer ;) Einfach die Felder per Stringverknüpfung verketten

SQL-Code:

SELECT * from tabelle where feld1||feld2||feld3 like "%suchbegriff%";

P.S: mit || ist die String-Verknüpfung gemeint, falls es nicht der Standard ist ...

[mkinzler]

@jim_raynor: Bist du sicher das diese Verkettung in der where-clause funktioniert?

[raiguen]

Moin :-)
hab mal grad eben den Vorschlag von jim_raynor getestet -> Jau, das geht so mit der Verkettung der Felder, sprich suchen über alle Felder! Zumindest bei meiner DB Absolute Database bekomme ich entsprechende Ergebnisse :-)
Hätt ich ehrlich gesagt nicht für möglich gehalten, dass das funzt...

[Hansa]

Das geht mit Sicherheit so. Ob die Ergebnismenge nun aus einzelnen Feldern oder zusammengesetzten besteht ist völlig egal. In diesem Ergebnisfeld wird dann nachgeschaut, ob der Suchbegriff darin vorkommt.

Das hier müsste auch gehen :

SQL-Code:

SELECT * from TABELLE where upper (Feld1||Feld2) like '%SUCH%';

Vielleicht noch mit ein paar Decimals per CAST bestücken als Würze. :mrgreen: Aber die Idee ist nicht schlecht ! Werde das in (zurückgestelltem) konkreten Fall sogar so machen. Da verwechselt ein Penner immer die Anrede und den Namen und wundert sich, daß nichts gefunden wird. :zwinker:

[MrSpock]

Hallo,

noch eine Bemerkung: wenn Feld1 den Eintrag "Mr" und Feld2 den Eintrag "Spock" hat liefert die Konkatenierungslösung bei der Suche nach "MrSpock" auch einen Treffer :mrgreen:

[Peter Mössinger]

Zitat:

Zitat von Hansa

SQL-Code:

SELECT * from TABELLE where upper (Feld1||Feld2) like '%SUCH%';

Vielleicht findest Du so aber zu viel. Stell Dir vor, Feld1 hört mit SU auf und Feld2 beginnt mit CH. Durch den Concat würde der Satz gefunden werden. Vielleicht sollte man es eher so machen:

SQL-Code:

SELECT * from TABELLE where upper (Feld1 || '-' || Feld2 || '-' ...) like '%SUCH%';

und '-' ist ein Wert, der in den Suchausdrücken nicht vorkommen kann.

[alzaimar]

Ich würde mal sagen, das das ein gutes Beispiel für ein falsches Tabellendesign (in Bezug auf die Abfrageanforderung) ist.
Damit ein DB-Server nicht unnötig ausgebremst wird, sollten die durchzusuchenden Felder indiziert sein. Falls ein 'LIKE' Operator verwendet werden muss, sollte kein Escape-Zeichen *vor* dem Suchstring auftreten, um die Suche mit Hilfe eines Indexes zu ermöglichen.
Dazu kann man mehrere Indexe erstellen, eines für jedes durchzusuchende Feld, oder man befolgt die die Grundregeln des DB-Designs, und erstellt eine separate Tabelle 'SearchFields' mit drei Feldern: Einem Link zum Masterdatensatz in der ursprünglichen Tabelle, Einem mit dem Inhalt, sowie eventuell noch Einem, das die Unterscheidung ermöglicht, ob es sich um das ursprüngliche 'Feld1', 'Feld2'... handelt.

Dann reduziert sich die Abfrage auf

SQL-Code:

select * 
  from Tabelle1 alias T1 join 
       SearchFields alias SF
         on SF.IDMaster = T1.ID
 where SF.Value = 'FooBar%'

Das ist bei einem Index auf SearchFields.Value optimal schnell.

[Mackhack]

Hi,

Zitat:

Zitat von alzaimar

...oder man befolgt die die Grundregeln des DB-Designs, und erstellt eine separate Tabelle 'SearchFields' mit drei Feldern: Einem Link zum Masterdatensatz in der ursprünglichen Tabelle, Einem mit dem Inhalt, sowie eventuell noch Einem, das die Unterscheidung ermöglicht, ob es sich um das ursprüngliche 'Feld1', 'Feld2'... handelt.

kannst du das mit der seperaten Tabelle bissi genauer erklaeren, das hoert sich interessant an. Kannst mir aber auch ne PM schreiben wenn du magst.

Dank dir auf jedenfall schonmal!

[Elvis]

Zitat:

Zitat von Mackhack

kannst du das mit der seperaten Tabelle bissi genauer erklaeren, das hoert sich interessant an.

Hat er doch schon... :gruebel:
naja hier etwas bildlicher:

• Haupttabelle:
  int ID
  Feld1
  Feld2
  FeldBlaBla
• SuchFeldTabelle
  int ID
  string Name
• SuchTabelle
  int LinkAufHauptTabelle
  int LinkAufSuchFeldTabelle
  string WertInDemGesuchtWerdenKann

SQL-Code:

SELECT Feld1
      ,Feld2
      ,FeldBlaBla
FROM  HauptTablle
WHERE ID in (SELECT LinkAufHauptTabelle
             FROM   SuchTabelle
             WHERE  WertInDemGesuchtWerdenKann like :SuchAusdruck)

Die zweite Tabelle könnte man hernehmen um den Suchwerten noch bestimmte Gruppen oder anderen Werte zu geben, die man beim Suchen als Einschränkung hernehmen könnte. Sozusagen ein Minihauch Metadaten in dem abstraken Beispiel.

[Hansa]

Zitat:

Zitat von MrSpock

wenn Feld1 den Eintrag "Mr" und Feld2 den Eintrag "Spock" hat liefert die Konkatenierungslösung bei der Suche nach "MrSpock" auch einen Treffer :mrgreen:

Völlig korrekt, MrSpock. Aber auch nur dann, wenn nicht irgendwo auch noch ein Leerzeichen falsch steht. :mrgreen: Feld1 müßte außerdem mit Mr enden und Feld2 direkt wieder mit Spock beginnen. Mein "Spezialfall"-Bsp. bezog sich auf so was :

ist es so hinterlegt :

Delphi-Quellcode:

Herr XY
z.Hd. Frau XY

oder so :

Delphi-Quellcode:

Herr 
XY z.Hd. Tipse

Der Sucher wirds nicht mehr wissen. Er weiß nur, daß irgendwas mit XY vorhanden sein muß. In der Anrede oder eben im Namen. Also muß ich sowieso alle relevanten Adressfelder durchsuchen. Konkateniere ich nun das Ergebnis, dann sind die Originalfelder egal. Die Adresse wird auf jeden Fall gefunden !

Die Theoretiker werden wohl auch bemängeln, daß LIKE, %, dazu noch vorne und hinten im Suchbegriff usw. langsamer ist als die Felder mit OR zu überprüfen. Das Wort Index ist ja bereits gefallen. Wenn ein Enduser allerdings den XY-Typ innerhalb von 10 Sek. findet, dann ist ihm das wohl viel lieber, als sich 1 Min. einen richtigen Suchbegriff auszudenken und dann 8,8 Sekunden zu warten, um gesagt zu bekommen, daß nichts gefunden wurde, weil das falsche Feld durchsucht wurde.

[alzaimar]

@Hansa: Es geht hier nicht um Zeitunterschiede von 1,2 Sekunden, wie Du so schön (aber falsch) süffisant angemerkt hast, sondern um drastische Geschwindigkeitsgewinne: Während die Suche über mit Hilfe eines Indexes, unabhängig von der Tabellengröße, in etwa konstant bleibt, wächst der Suchaufwand ohne Index linear: Doppelte Tabellengröße = Doppelte Suchzeit. Wenn man nur mit Tabellen von einigen Tausend Einträgen arbeitet, ist es wirklich egal, aber bei einigen Hunderttausend Einträgen macht sich das schon bemerkbar. Dann beträgt der Zeitunterschied etwa das 100 bis 1000-fache. Eine einfache Suche per Index ist in einigen 100 ms durchgeführt, während die sequentielle Suche ohne Index durchaus Minuten, wenn nicht sogar Stunden dauern kann.

Im Übrigen sind meinen Kunden Suchzeiten von 10 Sekunden nicht egal. Ein solches Schneckentempo erreiche ich höchstens bei Summierungen, ansonsten verlange ich von meiner DB, das die Suchergebnisse *sofort* erscheinen. Ein DB-Server sollte nicht suchen, sondern finden.

10 Sekunden... :wall:

Ich würde zwei Tabellen nehmen:
Aus einer Tabelle
T1:
int ID
string Name
string Feld1
string Feld2
string Feld3

werden zwei Tabellen
T2:
int ID
string Name

und
SearchFields:
int IDT2
int sfCode
string FieldValue

Ein Datensatz in T1 (1,'MyName','MyField1','MyField2','MyField3') wird auf ein Feld in T2 sowie drei Felder in SearchFields aufgeteilt:
T2:(1,'MyName')
SearchFields:
(1,1,'MyField1')
(1,2,'MyField2')
(1,3,'MyField3')

Und eine Suche in einem der Felder reduziert sich dann auf das bereits beschriebene:

SQL-Code:

select * 
  from T2 join 
       SearchFields alias SF 
          on SF.IDT2 = T2.ID 
 where SF.FieldValue ='MySearch'

Mit einem Index auf den SearchFields.FieldValues hast Du eine Recherchemöglichkeit, die ohne Verzögerung das Ergebnis liefert.

[WoGe]

Hallo,

man muss das Problem übrigens nicht in mehrere Tabellen zerlegen, folgendes geht, zumindest mit FB1.5 auch:

SQL-Code:

create view SuchAnschrift (
    KUNDENNO,
    ANSCHRIFT
    )
AS
select adr.KUNDENNO, adr.ANSCHRIFT1
from woreadr adr
where adr.ANSCHRIFT1 is not null
union
select adr.KUNDENNO, adr.ANSCHRIFT2
from woreadr adr
where adr.ANSCHRIFT2 is not null
union
select adr.KUNDENNO, adr.ANSCHRIFT3
from woreadr adr
where adr.ANSCHRIFT3 is not null
;

Über Performance kann ich leider nichts sagen, da ich hier nicht soviele Daten habe.

mfg
wo

[Angel4585]

:shock:
OK..
also nachdem ihr jetzt teilweise eine Nacht darüber geschlafen habt
und einige vielleicht sogar Albträume hatten..

Welche Version ist denn jetzt am Effektivsten um
in ALLEN Feldern einer Tabelle
nach einem Teilstring zu suchen?

:gruebel:

[alzaimar]

Wenn Du in ALLEN Felder einer Tabelle nach etwas suchen willst, dann ist die Tabelle falsch designed. Punkt. Denn wenn ich in mehreren Feldern etwas suchen will, enthalten diese semantisch äquivalente Inhalte, ergo gehören diese Felder in eine separate Tabelle.
Erzeuge eine Detailtabelle, wie vorher beschrieben. Alles Andere ist Rumgefrickele.

Wenn du allerdings nur ein paar hundert Datensätze hast, lohnt es den Aufwand nicht. Suche dann in allen Feldern durch OR verknüpft. Ob die indiziert sind, oder nicht, ist dann auch egal. Vermutlich wird das DBMS die Indexe gar nicht verwenden.

Bei vielen Records musst Du es richtig machen (Detailtabelle), sonst wird der DB-Server unnötig ausgebremst.

Dessenungeachtet ist es *immer* am Besten, man probiert es aus.