Quale tipo di dati deve essere utilizzato per l'archiviazione dei numeri di telefono in SQL Server 2005?
Devo memorizzare i numeri di telefono in una tabella. Per favore, suggerisci quale tipo di dati dovrei usare? Aspetta. Continua a leggere prima di premere risposta ..
Questo campo deve essere fortemente indicizzato poiché i rappresentanti di vendita possono utilizzare questo campo per la ricerca (inclusa la ricerca di caratteri jolly).
A partire da ora, ci aspettiamo che i numeri di telefono siano disponibili in diversi formati (da un file XML). Devo scrivere un parser per convertirlo in un formato uniforme? Potrebbero esserci milioni di dati (con duplicati) e non voglio legare le risorse del server (in attività come la preelaborazione troppo) ogni volta che arrivano alcuni dati di origine.
Eventuali suggerimenti sono benvenuti ..
Aggiornamento: Non ho alcun controllo sui dati di origine. Solo che la struttura del file xml è standard. Vorrei mantenere l'analisi xml al minimo. Una volta che è nel database, il recupero dovrebbe essere rapido. Un folle suggerimento qui intorno dovrebbe funzionare anche con la funzione di completamento automatico Ajax (in modo che i rappresentanti di vendita possano vedere immediatamente quelli corrispondenti). OMG !!
Questo include:
- Numeri internazionali?
- Estensioni?
- Altre informazioni oltre al numero effettivo (come "chiedi bobby")?
Se tutti questi fossero no, utilizzerei un campo 10 caratteri e eliminerei tutti i dati non numerici. Se il primo è un sì e gli altri due sono no, utilizzerei due campi varchar (50), uno per l'input originale e uno con tutti i dati non numerici con striping e usati per l'indicizzazione. Se 2 o 3 sono sì, penso che farei due campi e una sorta di parser pazzo per determinare quale sia l'estensione o altri dati e gestirli in modo appropriato. Ovviamente potresti evitare la seconda colonna facendo qualcosa con l'indice dove rimuove i caratteri extra durante la creazione dell'indice, ma farei solo una seconda colonna e probabilmente farei lo stripping dei personaggi con un trigger.
Aggiornamento: per risolvere il problema AJAX, potrebbe non essere così grave come si pensa. Se questo è realisticamente il modo principale in cui viene fatto qualcosa alla tabella, memorizzare solo le cifre in una colonna secondaria come Ho detto, e quindi rendere l'indice per quella colonna quello raggruppato.
Usiamo varchar (15) e certamente indice su quel campo.
Il motivo è che gli standard internazionali possono supportare fino a 15 cifre
Wikipedia - Formati numeri di telefono
Se si supportano i numeri internazionali, si consiglia l'archiviazione separata di un codice di zona mondiale o di un prefisso internazionale per filtrare meglio le query in modo da non ritrovarsi ad analizzare e verificare la lunghezza dei campi del numero di telefono per limitare le chiamate restituite agli Stati Uniti per esempio
Utilizzare CHAR (10) se si memorizzano solo numeri di telefono statunitensi. Rimuovi tutto tranne le cifre.
Probabilmente mi manca l'ovvio qui, ma un varchar non sarebbe abbastanza lungo per il tuo numero di telefono più lungo previsto?
Se am manchi qualcosa di ovvio, mi piacerebbe che qualcuno lo segnalasse ...
Vorrei usare un varchar (22). Abbastanza grande da contenere un numero di telefono nordamericano con estensione. Vorresti eliminare tutti i cattivi personaggi '(', ')', '-', o semplicemente analizzarli tutti in un formato uniforme.
Alex
usare varchar è piuttosto inefficiente. usa il tipo di denaro e crea un tipo di numero "phonenumber" dichiarato dall'utente e crea una regola per consentire solo numeri positivi.
se lo dichiari come (19,4) puoi persino memorizzare un'estensione di 4 cifre ed essere abbastanza grande per i numeri internazionali e richiede solo 9 byte di spazio di archiviazione. Inoltre, gli indici sono veloci.
SQL Server 2005 è abbastanza ottimizzato per le query di sottostringa per il testo nei campi varchar indicizzati. Per il 2005 hanno introdotto nuove statistiche nel riepilogo delle stringhe per i campi indice. Questo aiuta in modo significativo con la ricerca full text.
È abbastanza comune usare una "x" o "ext" per indicare le estensioni, quindi consentire 15 caratteri (per il supporto internazionale completo) più 3 (per "ext") più 4 (per l'estensione stessa) per un totale di 22 caratteri . Questo dovrebbe tenerti al sicuro.
In alternativa, normalizza sull'input in modo che qualsiasi "ext" venga tradotto in "x", dando un massimo di 20.
nvarchar con preelaborazione per standardizzarli il più possibile. Probabilmente vorrai estrarre le estensioni e memorizzarle in un altro campo.
Normalizza i dati quindi memorizza come varchar. La normalizzazione potrebbe essere complicata.
Dovrebbe essere un successo una tantum. Quindi, quando arriva un nuovo record, lo stai confrontando con dati normalizzati. Dovrebbe essere molto veloce.
Utilizzare un campo varchar con una limitazione di lunghezza.
Dal momento che è necessario adattarsi a molti formati di numeri di telefono diversi (e probabilmente includere cose come le estensioni ecc.) Potrebbe avere più senso trattarlo come faresti con qualsiasi altro varchar. Se potessi controllare l'input, potresti adottare una serie di approcci per rendere i dati più utili, ma non suona così.
Una volta che decidi di trattarlo semplicemente come qualsiasi altra stringa, puoi concentrarti sul superamento degli inevitabili problemi relativi ai dati errati, alla formulazione misteriosa del numero di telefono e a qualsiasi altra cosa apparirà. La sfida sarà nel costruire una buona strategia di ricerca per i dati e non come li conservi secondo me. È sempre un compito difficile dover gestire una grande quantità di dati che non hai avuto il controllo sulla raccolta.
Utilizzare SSIS per estrarre ed elaborare le informazioni. In questo modo avrai l'elaborazione dei file XML separati da SQL Server. È inoltre possibile eseguire le trasformazioni SSIS su un server separato, se necessario. Memorizza i numeri di telefono in un formato standard utilizzando VARCHAR. NVARCHAR non sarebbe necessario poiché stiamo parlando di numeri e forse di un paio di altri caratteri, come '+', '', '(', ')' e '-'.
Mi rendo conto che questo thread è vecchio, ma vale la pena menzionare un vantaggio della memorizzazione come tipo numerico ai fini della formattazione, in particolare in .NET framework.
IE
.DefaultCellStyle.Format = "(###)###-####" // Will not work on a string
È sempre meglio avere tabelle separate per attributi a più valori come il numero di telefono.
Poiché non hai alcun controllo sui dati di origine, puoi analizzare i dati dal file XML e convertirli nel formato corretto in modo che non ci siano problemi con i formati di un determinato paese e archiviarli in una tabella separata in modo che: l'indicizzazione e il recupero saranno entrambi efficienti.
Grazie.