Questo sito utilizza cookies solo per scopi di autenticazione sul sito e nient'altro. Nessuna informazione personale viene tracciata. Leggi l'informativa sui cookies.
In un progetto precedente dovevamo implementare una cosa simile alla tua, c'era un campo di ricerca unico che doveva cercare nell'elenco dei vari clienti inseriti nel db, inoltre doveva cercare oltre che nei vari campi del cliente(cognome, nome, ragione sociale) doveva cercare anche nel possibili indirizzi associati al cliente(una relazione 1->*) e nei possibili recapiti(sempre un'altra tabella e sempre 1->*).
Una soluzione furba che abbiamo trovato è stata quella di creare un tabella solo per la ricerca con queste tre colonne: Id, Value, IdCliente.
In value andavamo ad inserire il risultato della concatenazione dei valori in cui volevamo eseguire la ricerca(es. nome + ' ' + cognome + ' ' + ragioneSociale + ' ' + via + ' ' + cap + ' ' + ....).
E poi applicavamo un indice full text su questa colonna. Inoltre per dare priorità nella ricerca una volta estratti risultati verificavamo dove fosse il token(questo perchè se ad esempio uno cerca "milano" prima escono i clienti che si chiamano "Milano" e poi quelli che abitano a milano, infatti nella stringa i cognomi "Milano" si trovano ad un index inferiore degli indirizzi a "Milano").
Facendo così la ricerca è istantanea è da una sensazione "googleiana"
Ah dimenticavo ovviamente questa tabella la devi tenere aggiornata ogni volta che ci sono delle modifiche alle entità correlate.
Una furbata geniale...purtroppo non penso di poter fare un'unica table nel mio caso...
nel senso ho moltissimi recapiti, un numero discreto di nominativi e destinazioni...come faccio a unirle? con che criterio? forse sono io che non l'ho capito
Te non avevi ne union ne join nella ricerca, bell'incremento di prestazioni, una semplice select sostanzialmente, ma dici che posso anche io?
diversamente se no?
Certo che puoi, crei solo ridondanza, se hai spazio in abbondanza non dovrebbe essere un problema, dopo la prima importazione dei dati nella tabella che impiegherà del tempo, devi solo preoccupare di tenerla aggiornata, quindi magari invece di fare in fase di aggiunta di un record 3 query ne farai 4.
Su sql ogni tanto mi faccio remore che non esistono...
Posso si "unire le tabelle" e avere come prima (prima la ricerca era ristretta a gli indirizzi, avevo una tabella riassuntiva di tutti i recapiti, indistintamente) una tabella ricerca strutturata con un unico campo value in cui inserire tutto, indirizzi, nominativi ecc..ecc.. indistintamente....ovviamente uno per record....
E lasciare alla select il compito di rintracciare i dati, applicando solo una ricerca like...
Ma, operativamente parlando, avere un indice full text su una tabella che, idealmente, tra qualche tempo potrebbe avere 100mila record, è corretto?
si si, aggiornarla è il minimo, quella è una cosa da nulla, basta ampliare le query di insert, lo farei volentieri..
Ciao, guarda per farti vedere ho seguito adesso questa query la tabella ha più di 33000 record
ed il db è su una macchina virtualizzata(insieme ad altre 3) su di un server abbastanza vecchiotto:
Codice sorgente - presumibilmente VB.NET
SET STATISTICS TIMEON
SELECT TOP 100 Nominativo FROM fulltext.Cliente WHERE FREETEXT (Valore, 'rossi')
SET STATISTICS TIMEOFF
e i tempi sono questi:
Codice sorgente - presumibilmente Plain Text
(Righe interessate: 100)
Tempo di esecuzione SQL Server:
tempo di CPU = 0 ms, tempo trascorso = 3 ms.
Ultima modifica effettuata da tasx il 04/02/2015 alle 13:25
eh mi sembra abbastanza normale se hai 200 mila utenti avrai 200 mila record nella tabella di ricerca, come potresti averne un numero diverso?!
Non esattamente, ogni utente, se ditta, per esempio, può essere cercata per nome azienda e per indirizzo, quindi, 200mila aziende = 400mila record nel campo di ricerca. (non è il mio questo caso)
Ora, io spero ci siano questa molte di dati, così almeno ho lavoro assicurato... Però obbiettivamente, vista la ricerca generalizzata, potrei arrivare tranquillamente ad avere 200mila record.
Testo quotato
Postato originariamente da tasx:
Ciao, guarda per farti vedere ho seguito adesso questa query la tabella ha più di 33000 record
ed il db è su una macchina virtualizzata(insieme ad altre 3) su di un server abbastanza vecchiotto:
Codice sorgente - presumibilmente VB.NET
SET STATISTICS TIMEON
SELECT TOP 100 Nominativo FROM fulltext.Cliente WHERE FREETEXT (Valore, 'rossi')
SET STATISTICS TIMEOFF
e i tempi sono questi:
Codice sorgente - presumibilmente Plain Text
(Righe interessate: 100)
Tempo di esecuzione SQL Server:
tempo di CPU = 0 ms, tempo trascorso = 3 ms.
vediamo, 100 record in 3ms su 33mila
Anche fossero 200mila record posso dormire tranquillo allora...no?... in una manciata di millisecondi dovrebbe andare in porto la query....
Mi sento un po sollevato...
Penso opterò per combinare i vari suggerimenti
Grazie a tutti!
