In allen Felder suchen

[Luckie]

Hallo,
ich bräuchte noch mal eure Hilfe. Also wie man nach einem oder mehrern Feldern filtert, weiß ich.

SQL-Code:

SELECT name, vorname, telefonnumer FROM adressen where name='Müller'

Aber wie sieht die Abfrage aus, um in allen Feldern nach Müller zu suchen?

[omata]

Indem du alle aufführst?

SQL-Code:

SELECT name, vorname, telefonnumer 
FROM adressen 
WHERE name LIKE '%Müller%'
   OR vorname LIKE '%Müller%'
   OR telefonnumer LIKE '%Müller%'

[Luckie]

Ja, gut. Aber gibt es da keine elegantere Lösung?

[chaosben]

Ein bißchen eleganter ists imho so (verkürzt das Statement ein wenig):

SQL-Code:

SELECT name, vorname, telefonnumer FROM adressen where name || ' ' || vorname || ' ' || telefonnumer like '%Müller%'

Ist aber Geschmackssache. :)

[alzaimar]

Zitat:

Zitat von chaosben

SQL-Code:

SELECT name, vorname, telefonnumer FROM adressen where name || ' ' || vorname || ' ' || telefonnumer like '%Müller%'

Ist aber Geschmackssache. :)

Eher eine Frage der Performance. Während bei der Suche per LIKE über ein Feld eventuell ein Index verwendet werden kann, ist dies bei der 'Geschmackssache' unmöglich. In diesem Beispiel (

SQL-Code:

LIKE "%Müller%'

) wird das keinen großen Unterschied machen, aber bei Mustern à la "Müller%" kann ein guter Optimizer einen normalen Index für die Suche verwenden. Und wird es aller Wahrscheinlichkeit auch tun. (Es wird ja nach 'Müller' am Anfang eines Strings gesucht).

Versuche doch, einen Querygenerator zu schreiben, der über alle (Var)Char-Felder deiner Tabelle iteriert und das SELECT entsprechend aufbaut. Oder Du kapselst das in einer Stored Procedure.

Versuche, die Tabelle umzuformen, nur um eine 'elegante' Lösung herbeizuführen sind eine schöne Übung für die Normalisierung, taugen in der Praxis jedoch nur selten, da die Eleganz von der mangelnden Performance aufgefressen wird.

[Bernhard Geyer]

Schau dir mal für MySQL die Möglichkeiten einer Volltextsuche an.

[schlecki]

Zitat:

Zitat von chaosben

Ein bißchen eleganter ists imho so (verkürzt das Statement ein wenig):

SQL-Code:

SELECT name, vorname, telefonnumer FROM adressen where name || ' ' || vorname || ' ' || telefonnumer like '%Müller%'

Ist aber Geschmackssache. :)

Ein Problem bekommst du auch, wenn eines der Felder NULL ist... Dann ist nämlich der komplette Ausdruck auch NULL...

[Hansa]

Das LIKE hebelt alle Indices aus. Das mal vorab. Das nächste wäre einem zuzumuten, zwischen Groß/Kleinschreibung zu unterscheiden. Also kommt notgedrungen noch UPPER ins Spiel. Um das Ganze jetzt etwas einzuschränken, müssen die Felder also genau angesprochen werden. Siehe Omatas Beitrag.

[nahpets]

Hallo,

eine weitere Alternative wäre eine zusätzliche Spalte in der Datenbank, in die Du die Inhalte der zu durchsuchenden Spalten in reiner Großschrift ablegst.

SQL-Code:

SELECT name, vorname, telefonnumer FROM adressen where Sammelspalte like '%Müller%'

Beim Speichern der Daten musst Du dann halt (per Trigger?) diese zusätzliche Spalte füllen. Die Spalte muss "breit" genug sein, um die Inhalte der anderen Spalten bei jeweils maximaler Füllung aufnehmen zu können.

[jfheins]

Zitat:

Zitat von Bernhard Geyer

Schau dir mal für MySQL die Möglichkeiten einer Volltextsuche an.

Der Pferdefuß ist aber schon im 3. Satz zu finden:

Zitat:

MySQL unterstützt die Volltextindizierung und -suche. Ein Volltextindex ist in MySQL ein Index des Typs FULLTEXT. FULLTEXT-Indizes können nur bei MyISAM-Tabellen eingesetzt werden.

man muss sich also zwischen Transaktionen (InnoDB) und Volltextsuche (MyIsam) entscheiden. (Gibt bestimmt noch andere Vor- und Nachteile, aber das sind die beiden Funktionalitätsunterschiede über dich ich schon gestolpert bin)

[alzaimar]

Zitat:

Zitat von Hansa

Das LIKE hebelt alle Indices aus. Das mal vorab. ...

Zumindest MSSQL ist nicht ganz so blöd und verwendet bei einem LIKE 'Müller%' einen Index. Das mal hintenan.

[DeddyH]

Eben, das hat mit dem LIKE ja nur temporär zu tun. Es kommt darauf an, ob das Suchpattern bereits am Anfang eine Wildcard aufweist oder nicht.

[Hansa]

Habe mich offensichtlich nicht klar genügt ausgedrückt. 8) Wenn gesucht wird nach %NAME% etc. dann ist ein Index irrelevant. Auf der anderen Seite nützt es kaum was, anders zu suchen, sofern nur wenig bekannt ist. Man muss dann eben mit dem auskommen, was man hat. Ist nur der Namensbestandteil "ller" bekannt, dann nützt die Suche nach "Müller" wohl nichts. Das könnte auch "Schiller" sein usw. Das nächste wäre : ein Anwender muss unterstützt und nicht behindert werden. Selbet wenn eine Minute wegen Performance-Pronlemen gebraucht wird, um einen Datensatz zu suchen, dann ist das immer noch besser, als 10 Min. einen Ordner zu wälzen. :mrgreen:

[sx2008]

Mit dem Event OnFilterRecord kann man sehr flexibel nach allen Feldern filtern.
Es geht hier übrigens ums Filtern, nicht ums Suchen.
Natürlich werden zuerst alle Datensätze abgerufen; bei einer kleinen Datenmenge ist das aber eleganter und
mächtiger als sich mit Where-Bedingungen auseinanderzusetzen.