Typ danych dla numeru telefonu: VARCHAR, INT czy BIGINT?

To będzie więc pozorne pytanie roku, ale muszę zadać, ponieważ nie pierwszy raz to omawiam. Spójrz na następującą definicję tabeli:

Spójrz na kolumnę, from_numberktóra jest VARCHAR(45)teraz, ale będzie zawierała numer telefonu. Ponieważ nie wiem, ile numerów może mieć telefon na całym świecie, staram się pokryć prawie wszystkie z nich. Chcę zachować integralność bazy danych tak bardzo, jak to możliwe, więc uważam, że VARCHARnie jest odpowiednim typem do przechowywania tego rodzaju informacji - może się mylę, mówisz - więc myślę w zamian, INTa nawet BIGINT.

Kiedy definiuję kolumnę w Workbench, powinienem podać liczbę między nawiasami ()nie we wszystkich przypadkach, ale w tych, które wspominałem wcześniej, musiałem. Więc jeśli to zrobię: BIGINT()mam ten błąd:

Który poprowadzi mnie do zapoznania się trochę o tego typu MySQL tutaj . Zasadniczo informacja jest taka:

Duża liczba całkowita. ... Zakres bez znaku wynosi od 0 do 18446744073709551615.

Co sprawia, że ​​pytam: jaką wartość powinienem ustawić w nawiasach podczas definiowania BIGINT()typu. (Używam BIGINT, ponieważ nie wiem, czy INT może pomieścić tyle cyfr, ile mógłby mieć telefon - być może też się mylę). Jaki jest właściwy sposób na zaprojektowanie kolumny w bazach danych MariaDB / MySQL?

W każdym razie chciałbym poznać Twoją opinię, doświadczenie i oczywiście chciałbym uzyskać odpowiedź

Uwaga: Korzystam z najnowszej edycji MySQL Workbench do tworzenia schematu ER. Używam również MariaDB 10.0.x

Jak poradziłbyś sobie z numerem telefonu z numerem wewnętrznym, takim jak „+ 1-000-000-0000 ext 1234”?

Uwaga: „+” oznacza, że ​​należy stosować międzynarodowe zasady wybierania; więc z Ameryki Północnej system automatycznie rozpoznaje „011” w przypadku połączeń międzynarodowych itp.

A co z numerami telefonów, takimi jak „1-800-DBA-HELP”?

Zazwyczaj przechowuję numery telefonów jako tekst. To powiedziawszy, naprawdę zależy od tego, jak krytyczna jest kolumna z numerem telefonu. Jeśli korzystasz z automatycznych dialerów z tej kolumny, naprawdę chcesz upewnić się, że uwzględnione są tylko liczby, a dane reprezentują dobrze uformowane numery telefonów.

Możesz mieć osobne kolumny dla rozszerzeń i numery telefonów z tekstem, takie jak podany przeze mnie przykład „1-800-DBA-HELP”.

Wcześniej było napisane:

„Dzięki MariaDB możesz użyć computedpola, aby wyodrębnić tylko cyfry automatycznego dialera. Działa również w MySQL 5.7”.

W odpowiedzi na pytanie OP na ten temat („czy możesz trochę wyjaśnić, co mi mówisz?”), Oto wyjaśnienie.

Wiele systemów baz danych wprowadziło tę funkcję. Są to pola znane pod różnymi nazwami jako „ computed”, „ virtual” lub „ generated”, które pochodzą z wartości w innych polach. Moc tej funkcji będzie się różnić w zależności od RDBMS. Wiem, że mają je Oracle, Firebird, MariaDB, a teraz MySQL 5.7. Inni prawdopodobnie również.

Prostym przykładem może być kolumna nazwiska i kolumna obliczeniowa, która „przechowuje” (pamiętaj, że mogą być wirtualne - tj. Obliczane w locie lub mogą być fizycznie przechowywane na dysku) nazwisko jako wszystkie wielkie litery, dzięki czemu wyszukiwanie łatwiejsze. W ten sposób musisz tylko wyszukiwać na CAPs (używając, powiedzmy, LIKE), wiedząc, że dane są wyszukiwane w [ computed| virtual| generated] pole jest pisane wielkimi literami.

Pojęcie MySQL 5.7 jest wyjaśnione tutaj i tutaj . Jest w MariaDB nieco dłużej, a koncepcja została również wyjaśniona tutaj . Sugerowane są tutaj niektóre możliwe zastosowania , ale tak naprawdę ogranicza Cię tylko wyobraźnia. Można je postrzegać jako wygodny (i mniej podatny na błędy) zamiennik wyzwalaczy.

W konkretnym przypadku użycia można uzyskać numer wybierany z pola tekstowego „+” -> „00” (lub dowolnego innego międzynarodowego numeru kierunkowego). Tylko myśl.

Hmm Numery telefonów składają się z cyfr. Korzystanie z varchar umożliwia przechowywanie dowolnego rodzaju formatowania z (lub nie, z - lub. I szybko tworzy bałagan z twoimi danymi. Format numeru telefonu zależy od kraju, maska ​​powinna być powiązana z krajem. Rozszerzenie jest rozszerzeniem i jest opcjonalny, więc powinien być przechowywany w „polu rozszerzenia”. (również int.) W przypadku 1-800-DBA-HELP przekonwertowałbym to w locie i przechowywał rzeczywistą liczbę. Jeśli naprawdę potrzebujesz tych numer czytelny dla człowieka #, przechowuj go w osobnym polu varchar.

Zwykle przechowuję numery telefonów w postaci zwykłego tekstu . Formatowanie i wyświetlanie należy pozostawić do kodu klienta.

Tutaj, bardziej niż, jak przechowujesz? To, co zamierzasz zrobić z tym numerem telefonu, jest naprawdę ważne.

Jeśli Twoja firma chce wykonywać połączenia wychodzące z Twojego systemu, aplikacja wyodrębni tylko numery. Jeśli Twoja firma chce wykonywać połączenia międzynarodowe , przechowuj kod kraju i numer kierunkowy w osobnych kolumnach.

Jeśli Twoja firma chce raportować , aplikacja sformatuje i wyświetli osobno rozszerzenie i numery.

Z mojego zrozumienia, projektowanie uniwersalnego modelu danych dla numeru telefonu nie jest dobrym pomysłem. Każdy kraj ma inne numery, numery wewnętrzne i numery kierunkowe oprócz kodu kraju. Dowiedziałem się również, że niektóre kraje nie mają numeru kierunkowego.

To może nie odpowiedzieć na twoje pytanie, ale pomoże poszerzyć nasze zrozumienie. Dziękuję Ci.