C# / VB.NET - Autocomplete

Ok, quello che mi dici già mi rassicura.
smorzo il carico, elimino le ricerche inutili e ottimizzo la query.
Sono per ogni "categoria" di elementi che si possono cercare una tabella, nel senso che magari ho una tabella con le colonne atte a contenere nome cognome ed età per la persona, nome peso e lotto per l'oggetto e cosi via.
L'unica tabella complessa è quella degli indirizzi, in cui "via Garibaldi, roma" è diviso in 3 campi contenenti: via, Garibaldi, roma.
Non dovrebbe essere complessa, ma abboziamola insieme se ti va, tanto per darmi meglio l'idea di dove potrei errare.

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.

Ciao

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?

Puoi mica postare la struttura del db?

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..

eh mi sembra abbastanza normale se hai 200 mila utenti avrai 200 mila record nella tabella di ricerca, come potresti averne un numero diverso?!

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:

SET STATISTICS TIME ON
SELECT TOP 100 Nominativo FROM fulltext.Cliente WHERE FREETEXT (Valore, 'rossi')
SET STATISTICS TIME OFF

e i tempi sono questi:

(Righe interessate: 100)

Tempo di esecuzione SQL Server: 
 tempo di CPU = 0 ms, tempo trascorso = 3 ms.