Risposte:
In generale, esiste un compromesso tra "precisione" e "richiamo". Alta precisione significa che vengono presentati meno risultati irrilevanti (nessun falso positivo), mentre un alto richiamo significa che mancano meno risultati rilevanti (nessun falso negativo). L'utilizzo dell'operatore LIKE offre una precisione del 100% senza alcuna concessione per il richiamo. Una funzione di ricerca full-text offre molta flessibilità per ottimizzare la precisione per un migliore richiamo.
La maggior parte delle implementazioni di ricerca full-text usa un "indice invertito". Questo è un indice in cui le chiavi sono termini individuali e i valori associati sono insiemi di record che contengono il termine. La ricerca full-text è ottimizzata per calcolare l'intersezione, l'unione, ecc. Di questi set di record e di solito fornisce un algoritmo di classificazione per quantificare in che misura un determinato record corrisponde alle parole chiave di ricerca.
L'operatore SQL LIKE può essere estremamente inefficiente. Se lo applichi a una colonna non indicizzata, verrà utilizzata una scansione completa per trovare le corrispondenze (proprio come qualsiasi query su un campo non indicizzato). Se la colonna è indicizzata, la corrispondenza può essere eseguita con le chiavi di indice, ma con un'efficienza molto inferiore rispetto alla maggior parte delle ricerche di indice. Nel peggiore dei casi, il modello LIKE avrà i caratteri jolly iniziali che richiedono l'esame di ogni chiave di indice. Al contrario, molti sistemi di recupero delle informazioni possono abilitare il supporto per i caratteri jolly principali pre-compilando alberi di suffissi nei campi selezionati.
Altre caratteristiche tipiche della ricerca full-text sono
FTS implica l'indicizzazione delle singole parole all'interno di un campo di testo al fine di rendere veloce la ricerca attraverso molti record. L'uso di LIKE richiede comunque di effettuare una ricerca di stringhe (lineare o simile) all'interno del campo.
MySQL crea un indice dalle parole della colonna di ricerca full-text abilitata ed esegue ricerche su questo indice. MySQL utilizza un sofisticato algoritmo per determinare le righe corrispondenti alla query di ricerca.
Inoltre, da questa risposta SO :
Ci sono alcuni vantaggi nella ricerca full text.
indicizzazione:
Qualcosa di simile a:
WHERE Foo LIKE '%Bar';Non è possibile sfruttare un indice. Deve guardare ogni singola riga e vedere se corrisponde. Un indice full-text, tuttavia, può. In effetti, gli indici full-text possono offrire molta più flessibilità in termini di ordine delle parole corrispondenti, quanto vicine sono quelle parole, ecc.
Stemming:
Una ricerca full text può contenere parole. Se cerchi run, puoi ottenere risultati per "run" o "running". La maggior parte dei motori full text ha dizionari di staminali in varie lingue.
Risultati ponderati:
Un indice full-text può comprendere più colonne. Ad esempio, puoi cercare "torta di pesche" e l'indice può includere un titolo, parole chiave e un corpo. I risultati che corrispondono al titolo possono essere ponderati più in alto, in quanto più pertinenti, e possono essere ordinati per essere mostrati in alto.
svantaggi:
Un indice full-text può potenzialmente essere enorme, molte volte più grande di un indice B-TREE standard. Per questo motivo, molti provider ospitati che offrono istanze di database disabilitano questa funzione o almeno ne fanno pagare un extra. Ad esempio, per ultimo ho controllato, Windows Azure non supportava le query full-text.
Gli indici full-text possono anche essere più lenti da aggiornare. Se i dati cambiano molto, potrebbero esserci alcuni ritardi nell'aggiornamento degli indici rispetto agli indici standard.
Like usa solo caratteri jolly e non è poi così potente.
Il testo completo consente ricerche molto più complesse, tra cui And, Or, Not, anche risultati simili (SOUNDEX) e molti altri elementi.
Vorrei iniziare a guardare SQL CONTAINS () FREETEXT () e gli elementi di ricerca full text correlati per aiutare a comprendere meglio ciò che è disponibile.
La vera differenza sono le metodologie di scansione. Per la ricerca full-text, le parole (termini) vengono utilizzate come chiavi hash - ognuna delle quali è associata a una matrice di documenti in cui appaiono le chiavi (termini). È così:
Document sets = {d1, d2, d3, d4, ... dn}
Term sets = {t1, t2, t3, .. tn}Ora la matrice dei termini-documento (quale termine membro di quale documento) può essere rappresentata come:
t1 -> {d1, d5, d9,.. dn}
t2 -> {d11, d50, d2,.. dn}
t3 -> {d23, d67, d34,.. dn}
:
tn -> {d90, d87, d57,.. dn}Quando la richiesta arriva chiedendo "Ricevi tutti i documenti contenenti la parola / termine t1", {d1, d5, d9,.. dnviene restituito il set di documenti }.
È possibile hackerare uno schema di tabella non normalizzato per archiviare documenti: ogni riga nella tabella MySQL verrà considerata come "documento" e una colonna TEXT potrebbe contenere un paragrafo ecc. L'indice invertito conterrà i termini come chiavi hash e ID riga come ID del documento.
Ricorda che questa query SQL avrà più o meno prestazioni O (1). La query sarà indipendente da
Ad esempio questo SQL potrebbe essere attivato per estrarre tutte le righe corrispondenti alla parola data XYZ:
SELECT *
FROM my_table
WHERE MATCH (my_text_column) against ('XYZ' IN boolean mode) ;Avvertenza: se si aggiunge ORDER BY a questa query, i tempi di esecuzione varieranno in base ai diversi parametri, uno dei quali è il numero di righe / documenti corrispondenti. Quindi attenzione.
Il LIKE tuttavia non ha nulla di tutto ciò. È costretto a scansionare linearmente la frase / stringa e trovare tutti i termini corrispondenti. L'aggiunta di caratteri jolly aggiunge al caos. Funziona benissimo per stringhe di piccole dimensioni, come puoi immaginare, ma fallirà miseramente per frasi più lunghe. E sicuramente non confrontabile quando si ha un paragrafo o un'intera pagina di testo ecc.
FTS è più efficiente, potente (specialmente per Word Breaker e funzionalità di derivazione) ... ma controlla i tuoi requisiti perché a volte i DB non supportano tutte le lingue, ad esempio MSSQL non supporta il greco (consulta questa pagina http: // msdn. microsoft.com/en-us/library/ms176076(v=sql.110).aspx )