Logische SQL-Query problem...

Logische SQL-Query problem... (19 Beiträge, 168 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Ich sitze gerade mit ein Problem hier. Gefragt ist eine "freie Textsuche über alle Felder". Damit ist eine Suche nach 1 oder mehrere Suchwörter über alle Felder in eine Abfrage gemeint. Mit als Suchbegriff "amnesty wien" sollten alle Kontakten gefunden werden die irgendwo in der Daten 'Amnesty' und 'Wien' stehen haben. "Hr. Amnesty" aus "Wiener Neustadt" genauso wie "Fr. Wien" von "Amnesty International" in Brussel.

Um den WHERE-Statement auf zu bauen, gehe ich in eine Schleife durch alle Felder, und pro Feld hänge ich die Suchwörter dran, sodaß etwas wie "WHERE ( Name = wien OR Name = amnesty ) AND ( Ort = wien OR Ort = amnesty ) AND ( Orga = wien OR Orga = amnesty ) entsteht. (natürlich verwende ich LIKE mit entsprechende * und Anführungszeichen).

Syntaktisch stimmt der Abfrage schon, aber er liefert trotzdem nicht die gewünschte Ergebnisse. Wenn ich 'AND' wie im beispiel verwende, gibt er mir nur die Datensätze zurück die eine der Suchwörter in _alle_ Felder hat, oder wenn ich OR verwende, gibt er mir alle Datensätze zurück die eine der Suchwörter irgendwo stehen haben. Im 1. Fall kriege ich zuwenig (meistens gar kein) Ergebnisse zurück, im 2. Fall viel zuviele Ergebnisse...

Der große Frage: wie kann ich das WHERE-Statement so aufbauen das er nur die Datensätze zurückgibt die ich brauche?

Umgebung ist (leider) Access 2003 und Jet-SQL...

Ardjan

<stolz> Mein Sohn! </stolz>

!!! VIRUSWARNUNG !!!

WHERE (name="wien" or stadt=wien or orga=wien) and (name=anmesty or stadt=amnesty or orga=amnesty) and ...

Würd ich mal meinen.

1. Klammer checkt ob in irgendeinem Feld "wien" vorkommt
2. Klammer checkt ob in irgendeinem Feld "amnesty" vorkommt

dich interessieren nur die Datensätze, wo beides zutrifft => AND

Suche im Forum
Forums-FAQ
Kino 2006
Täglich frische Sudokus

09.03.2006, 15:21 Uhr - Editiert von Robert Craven, alte Version: hier

Danke!

Es schaut (nach der erste Test) so aus ob es das war...

Ich habe einfach durch die viele ANDs und ORs (und Klammern) das 'Wald' nicht mehr gesehen...

Eigentlich ganz einfach....

Ardjan

<stolz> Mein Sohn! </stolz>

!!! VIRUSWARNUNG !!!

wie wäre

where (name=wien or name=amnesty) and (orga=wien or orga=amnesty)

?

Das findet dann allerdings auch einen Herrn Wien in Wiener Neustadt.

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

Weil dann in 'name' UND 'orga' (UND 'city' UND...) eine der Suchterme stehen muß. Ich arbeite mit fast 30 Felder, und bei deiner Methode (ich habe sie zuerst auch versucht) kommen nur Ergebnisse zurück wenn in _Jeden_ Field eine der Suchterme steckt...

Ardjan

<stolz> Mein Sohn! </stolz>

!!! VIRUSWARNUNG !!!

Hmm... vielleicht per union?

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

select spalte1, spalte2 from tabelle1 where name = wien or name = amnesty or name = ... union select spalte1, spalte2 from tabelle1 where stadt = wien or stadt = amnesty or stadt = .... union select .....

-> Inwiefern das performant ist, mag ich jedoch nicht beurteilen

Student: Wäre das z.B. ein Thema für eine Dissertation?
Vortragender: Wenn Sie dieses Problem lösen, können Sie die Abkürzung über den Nobelpreis nehmen.

Hmm, ich habe nur ein Ausschnitt aus den Felder geschrieben. Insgesamt sind es 30 Felder aus 10 joined Tabellen.... Ich glaube nicht das Access damit klarkommt wenn ich das 30 mal mit Union verknüpfe....

Ardjan

<stolz> Mein Sohn! </stolz>

!!! VIRUSWARNUNG !!!

Den merke ich mir...
- Zuerst mal keine Bind-Variablen (also für jedes Union-Statement einen neuen Execution plan)
- dann eben Tonnen von Unions
- den Impliziten "Distinct"-Lauf danach (UNION ALL darf man ja hier nicht nehmen)

..........
Und du hast mich mal kritisiert (starker Topak), weil ich grundsätzlich in der 3.NF bleibe und net denormalisiere...

lies mal das statement wegen performanz

und nein, kritisiert habe ich dich nicht ... aber das was du geschrieben hast war schwer zu verdauen (bzw. zu verstehen)

Student: Wäre das z.B. ein Thema für eine Dissertation?
Vortragender: Wenn Sie dieses Problem lösen, können Sie die Abkürzung über den Nobelpreis nehmen.

Ich vermute, es liegt u.a. an Groß- und Kleinschreibung, = liefert ja nur dann true, wenn es wirklich exakt übereinstimmt.

Alternative: via regex oder ILIKE (sofern das die Umgebung unterstützt)
z.B.:
WHERE ... ILIKE '%wien%'

Eventuell könntest Du auch die Spalten zusammenfassen:
WHERE CONCAT(...) ILIKE '%wien%' OR CONCAT(...) ILIKE '%amnesty%'

Edith:
(ich hab noch nie mit Access/Jet-SQL gearbeitet, weiß also nicht, ob die Syntax ident ist - außerdem hab ich gerade diesen Artikel gefunden, wie ich nach einer Referenz gesucht habe: http://www.devguru.com/features/knowledge_base/A100219.html )

Es ist so bequem, unmündig zu sein.
Immanuel Kant (1724-1804)

09.03.2006, 22:22 Uhr - Editiert von thewanderer, alte Version: hier

Der 1. Antwort von Robert Craven hat sschon gepasst. Es war ein logisches Problem, kein syntaktisches.

Ardjan

<stolz> Mein Sohn! </stolz>

!!! VIRUSWARNUNG !!!

Dieser Beitrag bezieht sich auf eine ältere Version des beantworteten Postings!

Sorry, hab ich übersehen

Es ist so bequem, unmündig zu sein.
Immanuel Kant (1724-1804)

Danke für den Link, schaut interessant aus um schnell was nachzuschlagen...

Ardjan

<stolz> Mein Sohn! </stolz>

!!! VIRUSWARNUNG !!!

Ahem...
Wäre es net idealer, in solchen Fällen einen Full-Text-Index auf die zu durchsuchenden Attribute zu legen ? Man könnte sich ja einen Batch-Job um Mitternacht vorstellen, der Full-Text-Indizes in einer eigenen indizierten Tabelle anlegt und den nachher durchsuchen...

Denn ein WHERE attr LIKE '%irgendwas%' kann ja nun mal per Def net über einen Index gehen (wegen % vorne)...

Access...

Ardjan

<stolz> Mein Sohn! </stolz>

If it's too loud, then you're too old!
!!! VIRUSWARNUNG !!!

Du kannst es ja trotzdem lösen...
Eine tabelle "FULLTEXT" mit den Indizes - a la
ID  autowert
wort   text(255)
tabelle text(100)
attr_in_tabelle     text(100)
id_in_tabelle        long

Alle spalten indiziert  für schnelle Joins.
wort immer in Großschrift eintragen

Dort würde zB stehen:
1, "AMNESTY", "Kunden","Anschrift",212
2, "INTERNATIONAL","Kunden","Anschtift",212
.....

Eine query, wo überall "Amnesty International" auftaucht, würde dann ungefähr wie folft aussehen können:

SELECT DISTINCT a.tabelle,a.attr_in_tabelle,a.id_in_tabelle
FROM  fulltext as a INNER JOIN fulltext as b USING(tabelle,attr_in_tabelle,id_in_tabelle)
WHERE a.wort='AMNESTY' and b.wort='INTERNATIONAL'
;

Du müßtest dann eine Liste all der Tabellen, Attribute und ID's dort erhalten, in denen sowohl "Amnesty" als auch "International" vorkommen.
der Inner Join (Hoffe, daß die Syntax in Access so klappt, wenn net bekommst es hin) geht über Indizes, die wortsuche ebenfalls - das ist auch ungefähr der Mechanismus, der bei Fulltext-Indizes herangezogen wird.

Wenn du zusätzlich dem User Abfragen a la "AMNES*" erlauben willst, speicherst halt "A","AM","AMN","AMNE",... in der Fulltext-Tabelle.

Trigger gehen ja mal in Access net (*SCHLUCHZ*), aber du könntest das inserten ja notgedrungen in der Applikationslogik verpacken, dann ersparst du dir auch den Batch-Job (den ich aber trotzdem einbauen würde, weil ja evtl. andere "an den Forms vorbei" in der DB rumviechern.

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung