Quale tipo di dati deve essere utilizzato per l’archiviazione dei numeri di telefono in SQL Server 2005?

Ho bisogno di memorizzare i numeri di telefono in un tavolo. Si prega di suggerire quale tipo di dati dovrei usare? Aspettare. Si prega di leggere prima di colpire la risposta ..

Questo campo deve essere indicizzato pesantemente poiché i rappresentanti delle vendite possono utilizzare questo campo per la ricerca (inclusa la ricerca di caratteri jolly).

A partire da ora, ci aspettiamo che i numeri di telefono arrivino in una serie di formati (da un file XML). Devo scrivere un parser per convertirlo in un formato uniforms? Potrebbero esserci milioni di dati (con duplicati) e non voglio bind le risorse del server (in attività come la pre-elaborazione troppo) ogni volta che arrivano alcuni dati sorgente ..

Qualsiasi suggerimento è benvenuto ..

Aggiornamento: non ho alcun controllo sui dati di origine. Solo che la struttura del file xml è standard. Vorrei mantenere il parsing xml al minimo. Una volta nel database, il recupero dovrebbe essere veloce. Un pazzo suggerimento che succede qui è che dovrebbe funzionare anche con la funzione di completamento automatico di Ajax (in modo che i Sales Reps possano vedere immediatamente quelli corrispondenti). OH MIO DIO!!

Questo include:

  • Numeri internazionali?
  • Estensioni?
  • Altre informazioni oltre al numero effettivo (come “chiedi bobby”)?

Se tutti questi sono no, vorrei usare un campo di 10 caratteri e rimuovere tutti i dati non numerici. Se il primo è un sì e gli altri due no, utilizzerei due campi varchar (50), uno per l’input originale e uno con tutti i dati non numerici a strisce e utilizzati 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 gestirlo in modo appropriato. Ovviamente si può evitare la seconda colonna facendo qualcosa con l’indice in cui rimuove i caratteri in più durante la creazione dell’indice, ma farei solo una seconda colonna e probabilmente eseguirò lo stripping dei caratteri con un trigger.

Aggiornamento: per risolvere il problema AJAX, potrebbe non essere così brutto come pensi. 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 il cluster.

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

La ragione è 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 del mondo o codice paese per filtrare meglio le query in modo da non trovare l’analisi e il controllo della lunghezza dei campi del numero di telefono per limitare le chiamate restituite negli 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 non sarebbe un Varchar abbastanza a lungo perché il tuo numero di telefono più lungo previsto funzioni bene?

Se mi manca qualcosa di ovvio, mi piacerebbe se qualcuno lo indicasse …

Vorrei usare un varchar (22). Abbastanza grande da contenere un numero di telefono nordamericano con estensione. Vorresti togliere tutti i cattivi (‘,’) ‘,’ – ‘personaggi, o semplicemente analizzarli tutti in un unico formato uniforms.

alex

SQL Server 2005 è ottimamente ottimizzato per le sottostringhe per il testo nei campi varchar indicizzati. Per il 2005 hanno introdotto nuove statistiche sul riepilogo delle stringhe per i campi indice. Ciò aiuta in modo significativo con la ricerca di testo completo.

usare varchar è piuttosto inefficiente. usa il tipo di denaro e crea un tipo dichiarato dall’utente “phonenumber” e crea una regola per consentire solo numeri positivi.

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

nvarchar con pre-elaborazione per standardizzarli il più ansible. Probabilmente vorrai estrarre estensioni e archiviarle in un altro campo.

Normalizza i dati quindi memorizza come varchar. Normalizzare potrebbe essere complicato.

Questo dovrebbe essere un successo di una volta. Poi, quando arriva un nuovo record, lo stai confrontando con i dati normalizzati. Dovrebbe essere molto veloce.

Dal momento che è necessario gestire molti formati di numeri di telefono diversi (e probabilmente includere elementi come le estensioni ecc.) Potrebbe essere più sensato trattarlo come qualsiasi altro varchar. Se si potesse controllare l’input, si potrebbero adottare diversi approcci per rendere i dati più utili, ma non suona in questo modo.

Una volta che si decide di trattarlo come qualsiasi altra stringa, è ansible concentrarsi sul superamento degli inevitabili problemi relativi ai cattivi dati, al misterioso numero di telefono che si sta formando e a qualsiasi altra cosa compaia. La sfida sarà nel build una buona strategia di ricerca per i dati e non come li memorizzi secondo me. È sempre un compito difficile dover gestire una grande quantità di dati che non hai il controllo sulla raccolta.

Usa SSIS per estrarre ed elaborare le informazioni. In questo modo avrai l’elaborazione dei file XML separati da SQL Server. È anche ansible 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 dal momento che stiamo parlando di numeri e forse di un paio di altri caratteri, come ‘+’, ”, ‘(‘, ‘)’ e ‘-‘.

Utilizzare un campo varchar con una restrizione di lunghezza.

È abbastanza comune usare 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 su input in modo che qualsiasi “ext” venga tradotto in “x”, dando un massimo di 20.

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

IE

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

È 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 l’ indicizzazione e il recupero di entrambi sarà efficiente .

Grazie.