Ottenere gli stessi dati in più modi

Mi vengono subito in mente due opzioni.

Una ricerca generale che restituisce qualsiasi utente con un attributo corrispondente:

GetUsersByValue(value)

GetUsersByValue("1916-09-10")
  -> bbrown|Bob Brown|1916-09-10", schan|Sally Chan|1916-09-10

Anche se utile, potrebbe essere molto inefficiente e potrebbe generare molto rumore se si dispone di campi che contengono lo stesso tipo di tipi di dati. ad es. numeri di previdenza sociale e numeri di telefono. Quindi potresti preferire:

Una ricerca di attributi arbitraria che restituisce qualsiasi utente che corrisponde al valore dell'attributo specificato:

GetUsersByAttribute(name, value)

GetUsersByAttribute('DOB', '1916-09-10')
  -> bbrown|Bob Brown|1916-09-10", schan|Sally Chan|1916-09-10

Questo può essere risolto fornendo una funzione generica come

 GetUsersByWhereCondition(condition)

dove condition è una stringa arbitraria da utilizzare come parte di una clausola SQL "WHERE" come questa:

 GetUsersByWhereCondition("DOB=#1916-09-10# AND Realname='Foo'")

Questo ti permetterà di creare praticamente qualsiasi condizione di query che ti piace in fase di esecuzione in modo dinamico, anche se è una condizione complessa con sottoselezioni, logica booleana combinata o qualsiasi altra cosa supportata da SQL.

Ma attenzione, questa soluzione ha due potenziali svantaggi:

• l'implementazione del metodo deve aggiungere la condizione WHERE a una clausola SELECT SQL, senza la possibilità di controllare facilmente l'SQL (almeno, non senza implementare qualcosa come un parser SQL). Questo rende in qualche modo soggetto agli attacchi SQL injection. Quindi è importante sapere con certezza che il chiamante del metodo non trasmette alcun input non pubblicizzato attraverso il metodo. In alcuni contesti, questo è facile da garantire, in altri potrebbe diventare davvero difficile.

• questo ha il potenziale per rendere le parti del programma che chiamano tale funzione dipendente dal dialetto SQL del tuo database. Se quelle parti sono anche nel livello di accesso DB, questo probabilmente non sarà un grosso problema. Se le parti sono nel livello aziendale e vuoi mantenerlo indipendente dal dialetto SQL, potrebbe essere.

Quindi, se puoi vivere con quegli svantaggi, questa soluzione è molto potente e forse quello che stai cercando. Altrimenti usa una soluzione meno generica come quella di @JohnMee.

Ho avuto un problema simile per i dati dell'indirizzo una volta, la nostra soluzione era creare una singola colonna contenente tutti i dati ricercabili.

Scoprirai che l'indicizzazione di tutte le diverse colonne su cui vuoi effettuare la ricerca aumenterà notevolmente le dimensioni del tuo DB. In questo modo si riduce questo perché hai solo un indice di ricerca, anche se duplica i dati in una colonna di ricerca "disordinata". Tuttavia, ti consente di utilizzare le ricerche fuzzy sui dati, ad esempio memorizzi i nomi come valori soundex (o doppio-metaphone) e cerca quelli anziché il nome completo se i tuoi utenti hanno difficoltà a scriverli con precisione.

Potresti voler modificare i tuoi dati con alcuni prefissi (ad esempio, gli SSN potrebbero essere preceduti dal token 'SSN' o un delimitatore di token prima e dopo) e gli spazi dovranno essere rimossi o sostituiti, sebbene YMMV.

Dovrai gestire i dati della colonna man mano che gli utenti vengono creati o aggiornati, il che potrebbe essere troppo difficile - per noi dovevamo farlo solo durante la creazione. Dovrai anche gestire gli spazi, ma potresti non farlo, se vuoi cercare cognomi e cognomi senza nomi intermedi.

Stai duplicando i dati creando una tale "colonna di ricerca" speciale con questo approccio, ma ha funzionato molto bene. In alternativa puoi guardare alla creazione di un singolo indice da più colonne (alcuni DB consentono questo con funzionalità come l'indicizzazione della ricerca a testo libero) e semplicemente la ricerca invece.