Quale tipo di dati deve essere utilizzato per memorizzare i numeri di telefono in SQL Server 2005?

Question

Ho bisogno di memorizzare i numeri di telefono in una tabella.Per favore suggerisci quale tipo di dati dovrei usare?Aspettare.Per favore continua a leggere prima di rispondere..

Questo campo deve essere indicizzato in modo approfondito poiché i rappresentanti di vendita possono utilizzarlo per la ricerca (inclusa la ricerca con caratteri jolly).

A partire da ora, ci aspettiamo che i numeri di telefono arrivino in diversi formati (da un file XML).Devo scrivere un parser per convertire in un formato uniforme?Potrebbero esserci milioni di dati (con duplicati) e non voglio impegnare troppo le risorse del server (in attività come la preelaborazione) ogni volta che arrivano alcuni dati di origine.

Qualsiasi suggerimento è benvenuto..

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 inserito nel database, il recupero dovrebbe essere rapido.Un suggerimento folle che si sta diffondendo da queste parti è che dovrebbe funzionare anche con la funzione di completamento automatico di Ajax (in modo che i rappresentanti di vendita possano vedere immediatamente quelli corrispondenti).OH MIO DIO!!

Answer 1

Ciò include:

• Numeri internazionali?
• Estensioni?
• Altre informazioni oltre al numero effettivo (come "chiedi di Bobby")?

Se tutti questi valori fossero no, utilizzerei un campo di 10 caratteri ed eliminerei tutti i dati non numerici.Se il primo è 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 eliminati e utilizzati per l'indicizzazione.Se 2 o 3 sono sì, penso che farei due campi e una sorta di parser pazzo per determinare cos'è l'estensione o altri dati e gestirli in modo appropriato.Ovviamente potresti evitare la seconda colonna facendo qualcosa con l'indice in cui rimuove i caratteri extra durante la creazione dell'indice, ma creerei semplicemente una seconda colonna e probabilmente eliminerei i caratteri con un trigger.

Aggiornamento:per risolvere il problema AJAX, potrebbe non essere così grave come pensi.Se questo è realisticamente il modo principale in cui viene fatto qualsiasi cosa sulla tabella, memorizza solo le cifre in una colonna secondaria come ho detto, quindi rendi l'indice per quella colonna quello raggruppato.

Answer 2

Usiamo varchar(15) e certamente indicizziamo su quel campo.

Il motivo è che gli standard internazionali possono supportare fino a 15 cifre

Wikipedia - Formati dei numeri di telefono

Se supporti i numeri internazionali, ti consiglio di memorizzare separatamente un codice zona mondiale o un codice paese per filtrare meglio le query in modo da non ritrovarti ad analizzare e controllare la lunghezza dei campi del numero di telefono per limitare le chiamate restituite verso gli Stati Uniti per esempio

Answer 3

Utilizzare CHAR(10) se si memorizzano solo numeri di telefono statunitensi.Rimuovi tutto tranne le cifre.

Answer 4

Probabilmente mi manca l'ovvio qui, ma un varchar abbastanza lungo per il numero di telefono previsto più lungo non funzionerebbe bene?

Se io Sono manca qualcosa di ovvio, mi farebbe piacere se qualcuno lo facesse notare...

Answer 5

Vorrei usare un varchar(22).Abbastanza grande da contenere un numero di telefono nordamericano con interno.Vorresti eliminare tutti i fastidiosi caratteri "(', ')', "-" o semplicemente analizzarli tutti in un unico formato uniforme.

Alex

Answer 6

SQL Server 2005 è abbastanza ben ottimizzato per le query di sottostringa per il testo nei campi varchar indicizzati.Per il 2005 sono state introdotte nuove statistiche nel riepilogo delle stringhe per i campi indice.Ciò aiuta notevolmente con la ricerca del testo completo.

Answer 7

l'uso di varchar è piuttosto inefficiente.utilizzare il tipo money e creare da esso un tipo dichiarato dall'utente "phonenumber" e creare una regola per consentire solo numeri positivi.

se lo dichiari come (19,4) puoi anche memorizzare un'estensione di 4 cifre ed essere abbastanza grande per numeri internazionali, e richiede solo 9 byte di spazio di archiviazione.Inoltre, gli indici sono veloci.

Answer 8

nvarchar con preelaborazione per standardizzarli il più possibile.Probabilmente vorrai estrarre le estensioni e memorizzarle in un altro campo.

Answer 9

Normalizza i dati quindi archiviali come varchar.La normalizzazione potrebbe essere complicata.

Dovrebbe essere un successo una tantum.Quindi, quando arriva un nuovo record, lo confronti con i dati normalizzati.Dovrebbe essere molto veloce.

Answer 10

Poiché è necessario ospitare molti formati di numeri di telefono diversi (e probabilmente includere elementi come estensioni, ecc.), potrebbe essere più sensato trattarlo semplicemente 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 sembra così.

Una volta che decidi di trattarla semplicemente come qualsiasi altra stringa, puoi concentrarti sul superamento degli inevitabili problemi relativi a dati errati, formattazione misteriosa dei numeri di telefono e qualsiasi altra cosa possa apparire.Secondo me, la sfida sarà costruire una buona strategia di ricerca per i dati e non come archiviarli.È sempre un compito difficile dover gestire una grande quantità di dati sulla cui raccolta non hai il controllo.

Answer 11

Utilizzare SSIS per estrarre ed elaborare le informazioni.In questo modo avrai l'elaborazione dei file XML separata da SQL Server.Se necessario, puoi anche eseguire le trasformazioni SSIS su un server separato.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 '-'.

Answer 12

Usare un varchar campo con una limitazione di lunghezza.

Answer 13

È abbastanza comune utilizzare una "x" o "ext" per indicare le estensioni, quindi consenti 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 l'input in modo che qualsiasi "ext" venga tradotto in "x", dando un massimo di 20.

Answer 14

Mi rendo conto che questo thread è vecchio, ma vale la pena menzionare il vantaggio di archiviare come tipo numerico per scopi di formattazione, in particolare nel framework .NET.

CIOÈ

.DefaultCellStyle.Format = "(###)###-####" // Will not work on a string

Answer 15

È sempre meglio avere tabelle separate per attributi multivalore 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 particolare paese e memorizzarli in una tabella separata in modo che sia l'indicizzazione che il recupero saranno efficienti.

Grazie.