Dotaz: MYSQL typ stĺpca pre telefónne číslo

[adrinko]

Ahojte, prosím o radu - zamýšľam sa, aký typ stĺpca je najlepšie použiť pre uloženie telefónneho čísla v tvare 421900123456 (čísla budú mať 12 až 14 numerických znakov bez úvodných núl). Je lepší z hľadiska výkonu char alebo integer? (výkonnostne sa bavíme o miliónoch riadkov s číslami, ktoré sa môžu i opakovať) Vďaka

---

---

Odpovědi

[Ragzid]

Pokud nad tim nebudes provozovat nejake matematicke operace, tak urcite char/varchar s danou delkou...

[l4m4]

Budeš-li chtít podle telefonního čísla uloženého jako integer někdy vyhledávat, budeš muset v dotazech kreativně používat modulární aritmetiku... (nebo ho na ten string převádět).

[rADOn]

INT ti ztratí počáteční nuly, které ale mohou být v telefonním čísle signifikantní. Například mezinárodní prefix "00" bych považoval za celkem důležitý

[kuka]

U dotazu na vykon je dobre uvest, ceho vykon to ma byt. Treba pro vyhledani dle regularniho vyrazu to bude asi lepsi jako retezec, ciste z hlediska velikosti tabulky na disku asi jako cislo a podobne.

[DK]

mysql integer ma max 11 znaku, takze long, nebo varchar... nejlepsi bude asi varchar, pokud ty cisla nebudes scitat/odcitat

[Kit]

Určitě CHAR(14), to bude nejvýkonnější a nejlogičtější.

[mess]

Pozor na délku. Existují i telefonní čísla, která jsou delší. V jedné diskusi na StackOverflow doporučují lidi kolem 15 - 20 znaků s odkazem na nějaký standard ITU.

[Kit]

Délku obvykle neřeším (používám raději SQLite), ale napsal jsem to jako odpověď tazateli, který chtěl nejvýkonnější řešení pro 12-14 znaků. A tím je CHAR(14). Osobně bych klidně použil VARCHAR(255) a na výkon nekoukal. Nebude v tom žádný podstatný rozdíl.

[adrinko]

vďaka za odpovede. 14 znakov som uviedol preto, lebo to budú len mobilné čísla. Úvodné nuly mi netreba, lebo všetky čísla budú v medzinárodnom formáte s úvodnými nulami, takže tie viem k číslu doplniť, ak bude treba. Teoreticky by prichádzalo do úvahy ešte bigint, kde sa vojde i viac ako 14 čísiel. Čo si myslíte, nebolo by bigint lepšie ako char/varchar? Operácie ako sčítavanie delenie nebudem robiť, maximálne skupinovanie podľa jedného čísla (napr. zobrazenie všetkých záznamov, ktoré majú tel.číslo 421900123456, atď).

Podľa vašich rád sa zdá, že najlepšie bude použiť char/varchar.

[mess]

Podle mě je rozhodně lepší char/varchar. Bude se to lépe prohledávat a navíc, když časem narazíš na číslo, které úplně neodpovídá formátu, jaký jste si "vysnili", nebude takový problém ho uložit.

[rADOn]

Numericky sloupec ma min bitu, budes mit na nem mensi index. Ale pokud tech cisel nebudou kvanta tak to nebude velky rozdil. OTOH pokud budes potrebovat videt to cislo jako string, napriklad hledat cisla se stejnym prefixem, tak je char vyrazne lepsi (mysql afaik neumi indexy nad funkci) takze bych se drzel spis charu.

[Kit]

Telefonní číslo ve své podstatě není číslo, protože se s ním nedělají aritmetické operace, ale naopak se v něm používají pojmy typu "předčíslí", "klapka" apod, které jasně naznačují datový typ string.

[R]

A medzinarodny tvar nema na zaciatku nuly, ale znak "+".

[qwerty]

Jak který „mezinárodní“ tvar .

[Josef Kufner]

Když se tak podívám na svůj mobil, tak při vytáčení můžu napsat, krom '0' až '9' také znaky '*', '#', '+' a 'p'. To bych do intu necpal.

[pletiplot]

Určitě ne integer, pokud je nechceš sčítat. Zkus s jen představit, jak bys řadil různě dlouhá telefonní čísla - jako řetězec (tj "od kraje") nebo jako čísla (tj numericky, kratší první).

[George O.]

Telefonni cislo jsem v zivote nevidel v db jako integer. A to hned z nekolika duvodu:

1) Neni pevne dany format - nekdo zada cislo s +, nekdo s mezerama, nekdo s lomitkem a nemuzes riskovat konzistenci DB na zaklade javascriptove validace vstupniho formulare nebo nejakeho phone number parseru na strane serveru

2) Na vypisu by jsi z daneho intu, pokud by jsi chtel "hezky tvar", musel vyparsovat mezery, predvolby apod. - zbytecne

3) Telefonni cislo jen stezi byva klicovy udaj na primary/unique index - casto byva jen jako doplnujici info k uzivateli, cili selecty nad nim hadam provadet nebudes a ani zadne math operations na databazove urovni.

Na zaklade toho te nic nenuti k pouziti integeroveho typu, ktery neusetri nic (ba jeste prida par tezce zanedbatelnych, ale prida, taktu procesoru pri konverzi string to int), jen par Bytu mista v DB na polozku. Pokud tam planujes mit miliony useru, pak mluvime o jednotkach MB, coz v takovem pripade u nekolika GB databaze je, myslim, docela dost zanedbatelne

Tak prestan vymyslet chujoviny a dej si tam varchar 255, kdyz budes chtit setrit, tak varchar 20

[kuka]

Osobne bych urcite telefonni cislo neukladal jako integer, tvoje argumentace je nicmene z vetsi casti mimo

1. Do databaze se cislo jiste bude ukladat v nejakem normalizovanem tvaru, ne podle toho, kam nekdo napsal mezeru "do formulare", to by byl naprosty ulet.

2. Kazde operaci s cislem staci predradit konverzi z cisla na retezec. Sice bych to tak nedelal, ale zadnou velkou praci to urcite neda.

3. Tabulka s miliony zaznamu s telefonnimi cisly je v nasich podminkach pravdepodobne log hovoru nebo neco podobneho. V tom se podle cisla pravdepodobne vyhledavat bude, unique/primary index je v tomto pripade irelevantni.

Ze nejaka reprezentace usetri "jen par bytu na polozku" muze byt v nekterych nasazenich zasadni, fyzicka velikost tabulky ovlivnuje vykon naproste vetsiny operaci. V 99 procentech pripadu je to samozrejme jedno.