[MYSQL] Problema con MATCH - AGAINST

[angelomorto]

Ho una tabella così formata...

CREATE TABLE IF NOT EXISTS `descrizionefile` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `campo1` varchar(255) collate latin1_bin default NULL,
  `campo2` varchar(255) collate latin1_bin default NULL,
  `campo3` varchar(255) collate latin1_bin default NULL,
  `campo4` varchar(255) collate latin1_bin default NULL,
  `campo5` varchar(255) collate latin1_bin default NULL,
  `campo6` varchar(255) collate latin1_bin default NULL,
  `campo7` varchar(255) collate latin1_bin default NULL,
  `campo8` varchar(255) collate latin1_bin default NULL,
  `campo9` varchar(255) collate latin1_bin default NULL,
  `campo10` varchar(255) collate latin1_bin default NULL,
  PRIMARY KEY  (`id`),
  FULLTEXT KEY `campo1` (`campo1`),
  FULLTEXT KEY `campo2` (`campo2`),
  FULLTEXT KEY `campo3` (`campo3`),
  FULLTEXT KEY `campo4` (`campo4`),
  FULLTEXT KEY `campo5` (`campo5`),
  FULLTEXT KEY `campo6` (`campo6`),
  FULLTEXT KEY `campo7` (`campo7`),
  FULLTEXT KEY `campo8` (`campo8`),
  FULLTEXT KEY `campo9` (`campo9`),
  FULLTEXT KEY `campo10` (`campo10`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 COLLATE=latin1_bin;

Ho provato ad eseguire la seguente query...

 SELECT * ,
MATCH (
campo1, campo2, campo3, campo4, campo5, campo6, campo7, campo8, campo9, campo10
)
AGAINST (
'+fax +tedesco'
IN BOOLEAN
MODE
) AS attinenza
FROM descrizionefile
WHERE MATCH (
campo1, campo2, campo3, campo4, campo5, campo6, campo7, campo8, campo9, campo10
)
AGAINST (
'+fax +tedesco'
IN BOOLEAN
MODE
)
ORDER BY attinenza DESC
LIMIT 0 , 30

Sia la parola FAX che TEDESCO sono presenti all'interno di uno dei campi, quindi mi avrebbe dovuto dare come risultato almeno una riga, ma non mi trova nulla....ho sbagliato qualcosa?? :master:

[piero.mac]

devi creare una sola chiave con tutti i campi listati come fai con MATCH.

in match i campi devono avere lo stesso ordine con cui hai creato la chiave. In boolean mode puoi anche lavorare senza indice fulltext ma sara' abbastanza lenta la ricerca.

Nello specifico con fax (3 lettere) incappi poi nelle stop words poiche' di default la lunghezza minima delle stringhe da ricercare e' di 4 lettere.

[angelomorto]

Originariamente inviato da piero.mac
devi creare una sola chiave con tutti i campi listati come fai con MATCH.

in match i campi devono avere lo stesso ordine con cui hai creato la chiave. In boolean mode puoi anche lavorare senza indice fulltext ma sara' abbastanza lenta la ricerca.

Nello specifico con fax (3 lettere) incappi poi nelle stop words poiche' di default la lunghezza minima delle stringhe da ricercare e' di 4 lettere.

Cioè questa chiave dove e come la creo? e come posso diminuire il numeri di caratteri della stop words???

[piero.mac]

Originariamente inviato da angelomorto
Cioè questa chiave dove e come la creo? e come posso diminuire il numeri di caratteri della stop words???

FULLTEXT (campo1, campo2, campo3, campo4, campo5, campo6, campo7, campo8, campo9, campo10)

ma mi chiedo il senso che ha un indice su tanti campi.... sicuro della struttura della tabella? Nota che in boolean mode non serve l'indice... di fatto basterebbe chiedersi come potrebbe essere usato questo indice in una ricerca boolean.

Ci sono poi parecchie restrizioni di cui sarebbe bene rendersi conto. Diminuire i caratteri di stop words e' compito dell'amministratore del server. Il segno + rappresenta un AND per cui se una parola, per qualsiasi ragione, non fosse valida tutta la ricerca sarebbe compromessa.
Quindi nel tuo esempio against('+fax +tedesco' in boolean mode) verrebbe bloccata dal valore che trovi di default in ft_min_word_len che e' = 4. Verifica nella variabili.

Qui trovi tutto ed e' molto conveniente leggere tutti i paragrafi relativi e con molta attenzione.

http://dev.mysql.com/doc/refman/5.0/...xt-search.html

[angelomorto]

Originariamente inviato da piero.mac
FULLTEXT (campo1, campo2, campo3, campo4, campo5, campo6, campo7, campo8, campo9, campo10)

ma mi chiedo il senso che ha un indice su tanti campi.... sicuro della struttura della tabella? Nota che in boolean mode non serve l'indice... di fatto basterebbe chiedersi come potrebbe essere usato questo indice in una ricerca boolean.

Ci sono poi parecchie restrizioni di cui sarebbe bene rendersi conto. Diminuire i caratteri di stop words e' compito dell'amministratore del server. Il segno + rappresenta un AND per cui se una parola, per qualsiasi ragione, non fosse valida tutta la ricerca sarebbe compromessa.
Quindi nel tuo esempio against('+fax +tedesco' in boolean mode) verrebbe bloccata dal valore che trovi di default in ft_min_word_len che e' = 4. Verifica nella variabili.

Qui trovi tutto ed e' molto conveniente leggere tutti i paragrafi relativi e con molta attenzione.

http://dev.mysql.com/doc/refman/5.0/...xt-search.html

Allora, la mia necessità di avere un indice su tutti questi campi è perchè ho creato un archivio digitale in cui gli utenti per salvare i loro files devono compilare un form di 10 campi. Ora ho la necessità di creare un motore di ricerca sia per singolo campo che per tutti e 10 i campi.
Nelle varie ricerche ho letto che indicizzando i campi e creando una query sfruttando le funzioni MATCH - AGAINST potrei velocizzare di molto i tempi di ricerca, invece di usare la funzione LIKE per ogni parola che devo cercare su tutti i campi.
Ho capito bene oppure ho avuto un abbaglio? :master:

[piero.mac]

Originariamente inviato da angelomorto
Allora, la mia necessità di avere un indice su tutti questi campi è perchè ho creato un archivio digitale in cui gli utenti per salvare i loro files devono compilare un form di 10 campi. Ora ho la necessità di creare un motore di ricerca sia per singolo campo che per tutti e 10 i campi.
Nelle varie ricerche ho letto che indicizzando i campi e creando una query sfruttando le funzioni MATCH - AGAINST potrei velocizzare di molto i tempi di ricerca, invece di usare la funzione LIKE per ogni parola che devo cercare su tutti i campi.
Ho capito bene oppure ho avuto un abbaglio? :master:

Si tratta di un equivoco.

Per utilizzare un indice questo deve prima di tutto esistere. Intanto "IN BOOLEAN MODE" l'indice NON serve perche' una ricerca di questo tipo non potrebbe utilizzare un indice anche se esistesse.

In secondo luogo un indice deve essere creato con tutti i campi interessati dall'indice stesso e qui il tuo equivoco: non devi creare TANTI indici ma un SOLO indice che contenga tutti i campi previsti. E questi campi devono essere elencati nello stesso ordine nel MATCH. MA ripeto, IN BOOLEAN MODE NON serve l'indice. nel tuo caso il problema e' nella lunghezza minima della parola cercata. Attento poi che ci sono altre regole restrittive sulla ricerca.

la lunghezza massima oltre alla minima, le stop words cioe' parole che vengono ignorate, parole con una numerosita' di frequenza troppo intensa per cui verrebbe reso un record set imponente piu' altre delicatess ... leggi BENE il manuale.

Per la tabella 10 campi inseriti = 10 campi su tabella lascia supporre che la tabella forse potrebbe essere ottimizzata, ma non conoscendo il progetto su questo posso solo esprimere un dubbio.

[angelomorto]

Originariamente inviato da piero.mac
Si tratta di un equivoco.

Per utilizzare un indice questo deve prima di tutto esistere. Intanto "IN BOOLEAN MODE" l'indice NON serve perche' una ricerca di questo tipo non potrebbe utilizzare un indice anche se esistesse.

In secondo luogo un indice deve essere creato con tutti i campi interessati dall'indice stesso e qui il tuo equivoco: non devi creare TANTI indici ma un SOLO indice che contenga tutti i campi previsti. E questi campi devono essere elencati nello stesso ordine nel MATCH. MA ripeto, IN BOOLEAN MODE NON serve l'indice. nel tuo caso il problema e' nella lunghezza minima della parola cercata. Attento poi che ci sono altre regole restrittive sulla ricerca.

la lunghezza massima oltre alla minima, le stop words cioe' parole che vengono ignorate, parole con una numerosita' di frequenza troppo intensa per cui verrebbe reso un record set imponente piu' altre delicatess ... leggi BENE il manuale.

Per la tabella 10 campi inseriti = 10 campi su tabella lascia supporre che la tabella forse potrebbe essere ottimizzata, ma non conoscendo il progetto su questo posso solo esprimere un dubbio.

Proverò a fare delle prove cambiando il numero di stop words e creando un solo indice e vedo se risolvo il mio problema.
Per quanto riguarda i 10 campi, non sò se stai pensando di crearne uno solo con un carattere di divisione, ma non posso sfruttare questo metodo, perchè nomi dei campi cambiano a seconda della tipologia di gruppo in cui vengono salvati i files, quindi poi avrei dei problemi nel prelevare il nome del campo a seconda della sua posizione. E' un mezzo macello!!! :berto:

[piero.mac]

Originariamente inviato da angelomorto
Proverò a fare delle prove cambiando il numero di stop words e creando un solo indice e vedo se risolvo il mio problema.
Per quanto riguarda i 10 campi, non sò se stai pensando di crearne uno solo con un carattere di divisione, ma non posso sfruttare questo metodo, perchè nomi dei campi cambiano a seconda della tipologia di gruppo in cui vengono salvati i files, quindi poi avrei dei problemi nel prelevare il nome del campo a seconda della sua posizione. E' un mezzo macello!!! :berto:

azz... ma come devo scriverlo? Se utilizzi IN BOOLEAN MODE puoi rimuovere tutti i tuoi indici fulltext, non servono.

Per la tabella assolutamente no campi con dati non atomici come potrebbe essere campo con un carattere di divisione del contenuto. Ma men che meno fare un campo per ogni tipologia. Si fa una tabella di tipologie con descrizione e id che verra' associato alla tabella_base contenenti i nomi di file. Fare una tabella con valori dei campi messi come in uno schema di battaglia navale non ha proprio senso per un database.

taba_base
id_base - campo1 ... campo_ennesimo

tab_tipologia
id_tipologia - descrizione - quant'altro

tab_associazioni
id_assoc - id_base - id_tipologia

... vedi tu come vuoi fare.

[angelomorto]

Originariamente inviato da piero.mac
azz... ma come devo scriverlo? Se utilizzi IN BOOLEAN MODE puoi rimuovere tutti i tuoi indici fulltext, non servono.

Per la tabella assolutamente no campi con dati non atomici come potrebbe essere campo con un carattere di divisione del contenuto. Ma men che meno fare un campo per ogni tipologia. Si fa una tabella di tipologie con descrizione e id che verra' associato alla tabella_base contenenti i nomi di file. Fare una tabella con valori dei campi messi come in uno schema di battaglia navale non ha proprio senso per un database.

taba_base
id_base - campo1 ... campo_ennesimo

tab_tipologia
id_tipologia - descrizione - quant'altro

tab_associazioni
id_assoc - id_base - id_tipologia

... vedi tu come vuoi fare.

L'avevo capito, infatti il Boolean mode l'ho dovuto toglere perchè non sapevo fosse key sensitive...e a me serve una ricerca insensitive....
....per quanto riguarda le tabelle, più o meno è ciò che ho fatto io, solo coi campi divisi, perchè nel caso devo recuperare un solo campo, nel modo che dici tu mi verrebbe più complicato e avrei più codice da scrivere e quindi più funzioni....avendo invece i campi separati, una volta individuato il nome posso prelevare il dato senza eccesso di codice.
In pratica ho optato ad aver un database più complesso per risparmiare righe di codice