[MySQL/SQL] Zoeken en sorteren

[mocean]

Ik ben bezig met een simpel zoekscriptje, het hele ding is wat ingewikkelder maar komt min of meer op het volgende neer:

Tabel content

code:

ID , autonummer
TITLE , char
KEYWORDS , char
CONTENT , text

Daar zoek ik doorheen met
[SQL]
SELECT ID, TITLE
FROM content
WHERE TITLE LIKE '%zoekterm%'
OR KEYWORDS LIKE '%zoekterm%'
OR CONTENT LIKE '%zoekterm%'
[/SQL]

Ik wil dus graag sorteren op de manier waarom een record is gevonden. Zodat TITLE - matches bovenaan kunnen etc.
Ik kan dat oplossen door 2 queries te doen, maar dat is ook niet erg netjes. Is er een mogelijkheid in SQL / MySQL om te weten te komen door welk van de 3 WHERE statements het record is geselecteerd? En dan daarop sorteren?

Nu loop ik 3 keer door de recordset heen, en dan kijk ik of de zoekterm is gevonden in respectievelijk de titel, keywords of content, maar ik wil dat eigenlijk in SQL doen

[Bosmonster]

Zoek eens op FULLTEXT in de MySQL manual

[_Thanatos_]

Je zou die SELECT 3x kunnen doen en ze dan aan elkaar plakken met een UNION.

[Glimi]

Bosmonster schreef op 14 juli 2003 @ 13:00:
Zoek eens op FULLTEXT in de MySQL manual

.. zodat je iig ook indexes kan gebruiken LIKE %bla% zal nooit een index kunnen gebruiken omdat %bla% niet constant is
http://www.mysql.com/doc/en/Fulltext_Search.html

[intGod]

mocean schreef op 14 July 2003 @ 12:45:
Nu loop ik 3 keer door de recordset heen, en dan kijk ik of de zoekterm is gevonden in respectievelijk de titel, keywords of content, maar ik wil dat eigenlijk in SQL doen

Doe wat Thanatos zegt als volgt:

SQL:

SELECT
  ID
, TITLE
, 1 as foundIn
FROM
  CONTENT
WHERE 
  TITLE LIKE '%zoekterm%' 

UNION

SELECT
  ID
, TITLE
, 2 as foundIn
FROM
  CONTENT
WHERE
  KEYWORDS LIKE '%zoekterm%'

UNION

SELECT
  ID
, TITLE
, 3 as foundIn
FROM
  CONTENT
WHERE
  CONTENT LIKE '%zoekterm%'

[intGod]

Glimi schreef op 14 July 2003 @ 13:07:
[...]

.. zodat je iig ook indexes kan gebruiken LIKE %bla% zal nooit een index kunnen gebruiken omdat %bla% niet constant is
http://www.mysql.com/doc/en/Fulltext_Search.html

Maar vreet zo'n fulltext-index geen resources? Zeker als er regelmatig nieuwe records in komen? %bla% zal geen index zijn, maar als je je veld indexeert dan moet dat toch los lopen? Of is dat niet zo in MySql?

[_Thanatos_]

Maar vreet zo'n fulltext-index geen resources? Zeker als er regelmatig nieuwe records in komen? %bla% zal geen index zijn, maar als je je veld indexeert dan moet dat toch los lopen? Of is dat niet zo in MySql?

Het neemt wat ruimte in beslag, en als je die fulltext index vaak gebruikt, zal ie vast wel gaan cachen, maar dat is niet meer dan normaal (alleen maar goed zelfs).

Enne, ook al heb je een index op een veld, als je met LIKE selecteert (een paar andere clauses hebben hetzeflde effect) dan gebruikt ie nooit een index, zelfs geen fulltext.

[intGod]

_Thanatos_ schreef op 14 juli 2003 @ 13:56:
[...]
Enne, ook al heb je een index op een veld, als je met LIKE selecteert (een paar andere clauses hebben hetzeflde effect) dan gebruikt ie nooit een index, zelfs geen fulltext.

Klopt, had ik ff niet goed gelezen. Alleen bij = statements werkt een index. My bad.

[mocean]

Thanx voor de replies, ik ga morgen even een en ander proberen!

[mocean]

mocean schreef op 14 July 2003 @ 23:50:
Thanx voor de replies, ik ga morgen even een en ander proberen!

Ik zal maar even vertellen dat het gelukt is!

Truuk is om de velden die je wilt doorzoeken op 'fulltext' zet (bij char/varchar/text velden), dat kan heel makkelijk met bijvoorbeeld phpmyadmin.

je kan dan zoeken met

code:

WHERE MATCH (Table1.Value) AGAINST ('".$userinput."')

Wanneer je 2 velden wil doorzoeken van één tabel doe je:

code:

WHERE MATCH (Table1.Value, Table1.Value2) AGAINST ('".$userinput."')

Wanneer je de score wil weten (MySQL berekend namelijk hoe belangrijk je hit is) selecteer je

code:

MATCH (Table1.Value) AGAINST ('".$userinput."') AS score

Ik had het probleem dat ik met een JOIN bezig was, met eigenschapppen uit meerdere tabellen. De scores (om op te sorteren) heb ik bij elkaar opgeteld (mischien is vermenigvuldigen beter, geen idee precies):

code:

SELECT DISTINCT Tabel1.nID, ((MATCH (Tabel1.Value) AGAINST ('".$userinput."'))+
(MATCH (Tabel2.Value) AGAINST ('".$userinput."'))) AS score
 FROM Tabel1
Left JOIN ......
WHERE 
(MATCH (Tabel1.Value) AGAINST ('".$userinput."')) AND
(MATCH (Tabel2.Value) AGAINST ('".$userinput."'))

[ Voor 55% gewijzigd door mocean op 15-07-2003 14:50 ]

[ACM]

Wat een gedoe met unions, behalve dat mysql dat in v3.x nog niet eens kan...

SQL:

SELECT ID, TITLE,
(TITLE LIKE '%zoekterm%') AS foundInTitle,
(KEYWORDS LIKE '%zoekterm%') AS foundInKeywords,
(CONTENT LIKE '%zoekterm%') AS foundInContent
FROM content
WHERE TITLE LIKE '%zoekterm%'
OR KEYWORDS LIKE '%zoekterm%'
OR CONTENT LIKE '%zoekterm%'

intGod schreef op 14 July 2003 @ 14:33:
Klopt, had ik ff niet goed gelezen. Alleen bij = statements werkt een index. My bad.

Ook bij een like, en de vergelijkingsoperators als >, maar niet bij een like als er met een wildcard begonnen wordt.

[ Voor 30% gewijzigd door ACM op 15-07-2003 14:52 ]

[js303]

uh jonges en meisjes, indexen wordt dus niet NOOIT gebruikt bij LIKE:

MySQL also uses indexes for LIKE comparisons if the argument to LIKE is a constant string that doesn't start with a wildcard character. For example, the following SELECT statements use indexes:

mysql> SELECT * FROM tbl_name WHERE key_col LIKE "Patrick%";
mysql> SELECT * FROM tbl_name WHERE key_col LIKE "Pat%_ck%";

ik zie hier welliswaar alleen maar LIKE '%zoek%' staan dus is idd geen index op dit soort LIKEs, maar wou toch...

-- oh hmm voorlaatste post stond dit ook al aangegeven... ach ja.

[ Voor 12% gewijzigd door js303 op 15-07-2003 17:14 ]

[mocean]

Ik heb inderdaad een mysql 3.x versie

Maar dat Match Against gebeuren werkt echt super!

[Glimi]

js303 schreef op 15 July 2003 @ 17:14:
uh jonges en meisjes, indexen wordt dus niet NOOIT gebruikt bij LIKE:
ik zie hier welliswaar alleen maar LIKE '%zoek%' staan dus is idd geen index op dit soort LIKEs, maar wou toch...

-- oh hmm voorlaatste post stond dit ook al aangegeven... ach ja.

En de 4de, de 6de, _{de 7de} enz. enz.

[js303]

En de 4de, de 6de, de 7de enz. enz

nou ik wilde alleen uit de wereld helpen dat indexeren op wildcards helemaal niet zou kunnen. een index op 'blah%' kan dus wel... dat stond dus niet 4de, de 6de, de 7de. jee - dat gevit op elkaars posts...

[ Voor 46% gewijzigd door js303 op 22-07-2003 14:42 ]