Ik moet telefoonnummers opslaan in een tabel. Kunt u aangeven welk datatype ik moet gebruiken?
Wacht. Lees alsjeblieft verder voordat je op reageren klikt..
Dit veld moet zwaar worden geïndexeerd omdat verkopers dit veld kunnen gebruiken om te zoeken (inclusief zoeken met jokertekens).
Vanaf nu verwachten we telefoonnummers in een aantal formaten (van een XML-bestand). Moet ik een parser schrijven om naar een uniform formaat te converteren? Er kunnen miljoenen gegevens zijn (met duplicaten) en ik wil de serverbronnen niet vastzetten (in activiteiten zoals te veel voorverwerking) elke keer dat er brongegevens binnenkomen..
Alle suggesties zijn welkom..
Update: Ik heb geen controle over brongegevens. Alleen dat de structuur van het xml-bestand standaard is. Ik wil de xml-parsing tot een minimum beperken.
Als het eenmaal in de database staat, moet het snel worden opgehaald. Een gekke suggestie die hier rondgaat, is dat het zelfs zou moeten werken met de Ajax AutoComplete-functie (zodat verkopers de overeenkomende onmiddellijk kunnen zien). OMG!!
Antwoord 1, autoriteit 100%
Omvat dit:
- Internationale nummers?
- Extensies?
- Andere informatie naast het werkelijke aantal (zoals “vraag naar bobby”)?
Als dit allemaal nee is, zou ik een veld van 10 tekens gebruiken en alle niet-numerieke gegevens verwijderen. Als de eerste een ja is en de andere twee nee, zou ik twee varchar(50)-velden gebruiken, één voor de originele invoer en één met alle niet-numerieke gegevens gestript en gebruikt voor indexering. Als 2 of 3 ja zijn, denk ik dat ik twee velden en een soort gekke parser zou doen om te bepalen wat extensie of andere gegevens zijn en er op de juiste manier mee om te gaan. Natuurlijk zou je de 2e kolom kunnen vermijden door iets met de index te doen waarbij het de extra tekens verwijdert bij het maken van de index, maar ik zou gewoon een tweede kolom maken en waarschijnlijk de tekens verwijderen met een trigger.
Update: om het AJAX-probleem aan te pakken, is het misschien niet zo erg als je denkt. Als dit realistisch gezien de belangrijkste manier is om iets met de tabel te doen, sla dan alleen de cijfers op in een secundaire kolom, zoals ik al zei, en maak dan de index voor die kolom de geclusterde.
Antwoord 2, autoriteit 71%
We gebruiken varchar(15) en zeker index op dat veld.
De reden hiervoor is dat internationale standaarden tot 15 cijfers kunnen ondersteunen
Wikipedia – Telefoonnummerformaten
Als je internationale nummers wel ondersteunt, raad ik aan om een Wereldzonecode of landcode apart op te slaan om zoekopdrachten beter te filteren, zodat je niet merkt dat je de lengte van je telefoonnummervelden moet ontleden en controleren om het aantal teruggekeerde oproepen te beperken naar de VS bijvoorbeeld
Antwoord 3, autoriteit 8%
Gebruik CHAR(10) als u alleen Amerikaanse telefoonnummers opslaat. Verwijder alles behalve de cijfers.
Antwoord 4, autoriteit 5%
Ik mis hier waarschijnlijk het voor de hand liggende, maar zou een varchar net lang genoeg voor je langst verwachte telefoonnummer niet goed werken?
Als ik ietsiets voor de hand liggends mis, zou ik het geweldig vinden als iemand me erop zou wijzen…
Antwoord 5, Autoriteit 5%
Ik zou een varchar (22) gebruiken. Groot genoeg om een Noord-Amerikaans telefoonnummer met extensie te houden. Je zou alle akelige ‘(‘ ‘,’) ‘willen uitstralen, of gewoon parseren in één uniform formaat.
Alex
Antwoord 6, Autoriteit 3%
SQL Server 2005 is behoorlijk goed geoptimaliseerd voor substring-query’s voor tekst in geïndexeerde varcharvelden. Voor 2005 introduceerden ze nieuwe statistieken aan de stringoverzicht voor indexvelden. Dit helpt aanzienlijk met volledige tekst zoeken.
Antwoord 7, Autoriteit 3%
Gebruik varchar is behoorlijk inefficiënt. Gebruik het geldtype en maak een gebruiker aangegeven type “Phonenumbum” eruit en maak een regel om alleen positieve cijfers toe te staan.
Als u het als (19,4) declareert, kunt u zelfs een 4-cijferige extensie opslaan en groot genoeg zijn voor internationale cijfers, en heeft slechts 9 bytes opslag. Ook zijn indexen snel.
Antwoord 8, Autoriteit 2%
Nvarchar met preprocessing om ze zoveel mogelijk te standaardiseren. Je wilt waarschijnlijk extensies extraheren en ze op een ander veld opslaan.
Antwoord 9, Autoriteit 2%
Normaliseer de gegevens en bewaar dan als een varchar. Normaliseren kan lastig zijn.
Dat zou een eenmalige hit moeten zijn. Dan is er als een nieuw record binnenkom dat u het vergelijkt met genormaliseerde gegevens. Zou erg snel moeten zijn.
Antwoord 10, Autoriteit 2%
Aangezien u veel verschillende telefoonnummerformaten nodig hebt (en waarschijnlijk dingen zoals extensies enz.) Het kan het meest logisch zijn om het gewoon te behandelen zoals een andere varchar. Als u de invoer zou kunnen beheersen, kunt u een aantal benaderingen nemen om de gegevens nuttiger te maken, maar het klinkt niet zo.
Als u eenmaal besluit om het eenvoudigweg te behandelen als een andere reeks, kunt u zich concentreren op het overwinnen van de onvermijdelijke problemen met betrekking tot slechte gegevens, mysterieuze telefoonnummer die formatteren en wat er nog meer zal verschijnen. De uitdaging zal zijn om een goede zoekstrategie voor de gegevens te bouwen en niet hoe je het naar mijn mening opslaat. Het is altijd een moeilijke taak om te gaan met een grote stapel gegevens die u geen controle had over het verzamelen.
Antwoord 11, Autoriteit 2%
Gebruik SSI’s om de informatie uit te halen en te verwerken. Op die manier hebt u de verwerking van de XML-bestanden gescheiden van SQL Server. U kunt ook de SSIS-transformaties op een afzonderlijke server doen, indien nodig. Bewaar de telefoonnummers in een standaardformaat met behulp van varchar. NVARCHAR zou onnodig zijn, omdat we het hebben over cijfers en misschien een paar andere tekens, zoals ‘+’, ”, ‘(‘, ‘)’ en ‘-‘.
Antwoord 12, Autoriteit 2%
Gebruik een varcharVELD met een lengtebeperking.
Antwoord 13, Autoriteit 2%
Het is vrij gebruikelijk om een ”x” of “ext” te gebruiken om extensies aan te geven, dus toestaan 15 tekens (voor volledige internationale ondersteuning) plus 3 (voor “EXT”) plus 4 (voor de extensie zelf) van 22 tekens. Dat zou je veilig moeten houden.
Alternatief, normaliseren op invoer, zodat elke “ext” wordt vertaald naar “X”, met een maximum van 20.
Antwoord 14, Autoriteit 2%
Het is altijd beter om afzonderlijke tabellen te hebben voor multi-gewaardeerde kenmerken zoals telefoonnummer.
Zoals u geen besturing hebt op brongegevens, kunt u de gegevens uit het XML-bestand ontleden en deze in het juiste formaat converteren, zodat er geen probleem met formaten van een bepaald land zal zijn en deze in een aparte tabel opslaan, Dat indexeren en ophalen beide zullen efficiënt zijn .
Bedankt.
Antwoord 15, Autoriteit 2%
Ik realiseer me dat deze draad oud is, maar het is de moeite waard om een voordeel te vermelden als een numeriek type voor opmaakdoeleinden, specifiek in .NET Framework.
IE
.DefaultCellStyle.Format = "(###)###-####" // Will not work on a string
Antwoord 16
Gebruik de gegevenstype lang in plaats daarvan .. GEBRUIK INT GEBRUIK IN INT omdat het alleen hele getallen tussen -32.768 en 32.767 toestaat, maar als u een lange gegevenstype gebruikt, kunt u nummers tussen-2.147.483.648 en 2.147.483.647 invoegen.