Newsgroup: it.comp.www.php
Titolo: Sistema di ricerca potente

Salve a tutti.
Sto sviluppando un sistema di inserimento e ricerca di record
all'interno di un database.
Mentre l'inserimento è banale, la ricerca non lo è altrettanto
perchè è effettuata a partire da keyword scritte liberamente
dall'utente.
Prendiamo l'esempio di eBay. Se si cerca "bello" ci si aspetta che ebay
restituisca una serie di risultati contenenti tale parola, ma non
record con parole che contengano il pattern "bello" (esempio ribello,
zimbello, ecc).
A questo punto, esistono delle "regole" o dei sistemi per effettuare
delle ricerche in modo mirato o devo scervellarmi per ricavarle da me?
Non vorrei riscoprire l'acqua calda....
Grazie
Franco

delle ricerche in modo mirato o devo scervellarmi per ricavarle da me?
Un sistema e' quello di preparare una sorta di vocabolario controllato,
tipo
ID     Keyword
12733  bello
L'inserimento diventa non banale :-) perche' la pagina $URL contiene un
paio di migliaia di keyword, magari. Quindi, avendo forse un milione di
URL in memoria, ti trovi due miliardi di voci nella tabella
ID	URL_ID
...ma, d'altro canto, quella tabella si indicizza benissimo, anzi, puoi
perfino segmentarla (cento tabelle da venti milioni di record l'una), o
suddividerla su piu' macchine.
Quando l'utente ti invia una query per
	cello
lo cerchi nel vocabolario e se non lo trovi sai gia' che non troveresti
niente nel super-archivio; quindi puoi dirlo, o magari fare una diversa
ricerca: "Quali codici CHE HO hanno un codice it-soundex simile?". E al
cliente fai comparire
	Volevi forse dire CIELO, VELLO, GELLO?
Una parola che compare in piu' del, diciamo, 90% degli $URL, la togli -
eliminando in una botta sola novecentomila record di super-archivio - e
la metti in un vocabolario secondario "BANALI", e avverti:
	Il termine "IL" e' stato eliminato dalla ricerca
Per fare la ricerca, a questo punto fai una SELECT di tutti gli URL che
corrispondono all'ID della prima keyword, ed ottieni una tabella TEMP_1
che contiene solo gli URL_ID, distinti, e indicizzati. Poi, cerchi l'ID
della seconda keyword, ed ottieni TEMP_2. Fai una LEFT JOIN fra le due,
del tipo
CREATE TEMPORARY TABLE TEMP_3
SELECT DISTINCT TEMP_1.URL_ID FROM
TEMP_1 LEFT JOIN TEMP_2
ON (TEMP_1.URL_ID = TEMP_2.URL_ID)
WHERE TEMP_2.URL_ID IS NOT NULL;
DROP TABLE TEMP_2; DROP TABLE TEMP_1; ALTER TABLE TEMP_3 RENAME TO TEMP_1;
CREATE UNIQUE INDEX TEMP_1_NDX ON TEMP_1(URL_ID);
...e cosi' ripeti per tutti i successivi KEY_ID... tranne che appena ti
accorgi che "SELECT COUNT(URL_ID) FROM TEMP_1;" e' zero, vuole dire che
nessuna pagina contiene tutte le keyword selezionate.
====
Potrebbe convenirti fare, prima, un SELECT COUNT(*) FROM ARCHIVIO WHERE
KEY_ID=$keywordid[$i], per ogni $i, per partire dal $i che ti da' conto
minore - se qualcuno cerca DISCROMATOPSIA INFANTILE OCCHIALI, e' meglio
se esamini le temporanee di DISCROMATOPSIA (25 hits) e INFANTILE (1971)
per scoprire che un incrocio ti da' zero pagine, senza fare la join con
OCCHIALI che di hit ne ha 48922 :-)
Leonardo
-- 
Geordie - he's a man, there's little doot about't,
He's done all he can, wha' can do withoot't?
Doon there cam a blade, linkin' like me lordie,
He wad drive a trade, a' the loom of Geordie.

Grazie mille Leonardo, sei stato veramente esaustivo! Ho dato una letta
veloce al tuo post e ti ringrazio molto per le dritte!
Nei prossimi giorni proverò ad implementare quello che mi hai
suggerito, e se necessario, posterò ancora :-)
Ciao
Franco

 OCCHIALI che di hit ne ha 48922 :-)
mai sentito parlare di ricerca fulltext e match against()?

 suggerito, e se necessario, posterò ancora :-)
fatti un piacere, e leggi qui:
http://dev.mysql.com/doc/refman/5.1/en/fulltext-search.html

 wrote:


Vagamente, ma non ho mai indagato sulle performances o sulla
flessibilita'.


> mai sentito parlare di ricerca fulltext e match against()?
no..

 
http://dev.mysql.com/doc/refman/5.1/en/fulltext-search.html
sì, questa soluzione "precotta" è l'ideale, penso. anche qui ho dato
un'occhiata veloce.
Proverò anche questo nei prossimi giorni..
Grazie!
Franco

 flessibilita'.
si nota

si nota
Non fraintendermi: averlo gia' pronto cotto e mangiato in un RDBMS
e' utilissimo, specie se puoi lavorare proprio su quel RDBMS, e in
molti casi poter dire "Spiacente - la piattaforma non lo supporta"
e' un salvavita (l'alternativa e' un bordello di collaudi, test, e
inevitabili errori, sviste, cambi di rotta, riunioni col cliente e
via dicendo; e poi, fin troppo spesso una "feature" non e' che sia
veramente necessaria).
Pero', magari anche un sistema piu' rozzo e farraginoso, in almeno
alcuni casi, puo' avere una sua utilita'.
Per esempio: se uno volesse considerare "banale" una keyword se e'
presente nel 70% dei testi anziche' nel 50%, o limitare le keyword
a un gruppo ristretto? O non usare l'engine MyISAM? O magari usare
un sistema di sinonimi?
Detto questo, non c'e' dubbio che la risposta migliore al problema
di Pianoska sia stata la tua, ne' che io la ignorassi!


 un sistema di sinonimi?
Questa è una bella gatta da pelare. (in ogni caso, tra l'altro)
Tac
-- 
Using Opera's revolutionary e-mail client: 
http://www.opera.com/mail/

Questa č una bella gatta da pelare. (in ogni caso, tra l'altro)
Mah... non ci ho pensato molto su, pero' se la mappatura id <-> keyword
fosse del tipo uno a molti? L'utente inserisce "telescopio" e riceve lo
stesso ID che se avesse inserito "cannocchiale"... e lo so che non sono
molto sinonimi, ma tanto per spiegarmi. Tanto, il passaggio ID->keyword
non viene fatto mai - mi pare - e comunque la keyword originaria e' pur
sempre rimasta disponibile all'applicativo.
(Si fa per parlarne, eh! Non ho mai avuto a che fare con ricerche testo
di dimensioni colossali, tanto meno in PHP/MySQL)


 di dimensioni colossali, tanto meno in PHP/MySQL)
Non ti perdi niente.


Ho trovato molto utili i vostri suggerimenti, la ricerca sembra
funzionare bene, anche se per adesso la sto provando su un numero
piccolissimo di record (200 circa).
il mio nuovo "problema". uso MySQL versione 1.4, quindi la ricerca
MATCH AGAINST non prevede la clausula IN NATURAL LANGUAGE MODE.
Come viene eseguita la ricerca rispetto alla versione superiore?
Vengono comunque tralasciate le parole "comuni"?
Grazie
Franco

passare dal via).
Eh! Poterlo fare sempre... :-|


 qui basterebbe, e occorrerebbe, cambiare due righe nei sorgenti).
Negli ultimi giorni non ho potuto fare a meno di notare questo tuo virtuosismo
di "wrapping giustificato", è bellissimo :-) Ma com'è che fai? C'è da diventar
matti. Io, per trovare la via di giustificare queste tre righe, c'ho messo due
ore. Mi vengono più facili le cornici concentriche della settimana enigmistica
E infatti, il punto a chiusura del periodo, non ce l'ho fatta ad inserirlo :-)
-- 
mailto: y = i
----------------------------------------
Vivo nel terrore di non essere frainteso 
(Oscar Wilde)

matti.
Cosi', come ultima difesa per le cazzate che sparo, posso rifugiarmi nella
seminfermita' mentale :-)
Leonardo previdente


 Eh! Poterlo fare sempre... :-|
A volte conviene. Altrimenti firmi per 1000 euro una cosa che ti tira  
scemo un anno con minaccie (vere o fasulle che siano) di causa assortite.


scemo un anno con minaccie (vere o fasulle che siano) di causa assortite.
Been there, done that, got the T-Shirt (e no, non l'avevo firmato io quel
contratto: io avevo suggerito la fuga precipitosa).


 scapperei.
Ti presto il motorino (montiamo in due però, vengo anch'io..).


Infatti. ("ma perchè non si può ? Google lo fa!..")
Avessi un centesimo per ogni volta che ho sentito
	"Ma perche' non si puo'? ${X} lo fa..."
con ${X} = applicazione sviluppata in tempi, con budget, e da una squadra
che supera di almeno quattro ordini di grandezza il disponibile...
(Questo thread sta diventando un piangersi sulla spalla :-D )


 (Questo thread sta diventando un piangersi sulla spalla :-D )
Piangere non costa nulla.
