Poprawny typ danych dla atrybutu Telefon w encji Student to typ tekstowy, ponieważ numer telefonu nie jest zwykłą liczbą, tylko ciągiem znaków o określonej strukturze. Mamy tam znak plus na początku, potem numer kierunkowy kraju, często spacje, czasem myślniki, nawiasy. System informatyczny nie powinien wykonywać na tym polu działań arytmetycznych, tylko przechowywać dokładnie to, co użytkownik wpisał. W bazach danych i w większości języków programowania przyjętym standardem jest traktowanie numerów telefonów jako stringów, właśnie po to, żeby nie tracić formatu i nie usuwać znaków specjalnych. Moim zdaniem to jedna z takich pułapek początkujących: skoro są cyfry, to kusi, żeby dać typ liczbowy. A potem wychodzą kwiatki, typu ucinanie zera na początku, problemy z numerami międzynarodowymi, brak możliwości zapisania +48 albo numeru wewnętrznego. W praktyce w modelu danych stosuje się typ tekstowy (np. VARCHAR o rozsądnej długości) i ewentualnie nakłada się walidację po stronie aplikacji lub bazy, np. wyrażeniem regularnym, żeby pilnować formatu zgodnego z E.164 (+48123456789 itd.). Dobre praktyki mówią też, żeby nie łączyć w jednym polu różnych znaczeń, więc jeśli oprócz numeru trzeba przechowywać np. opis typu telefonu (komórkowy, stacjonarny, służbowy), to lepiej dać osobny atrybut albo nawet osobną tabelę. Sam numer jednak zawsze jako tekst, bo jego „wartość” logiczna to identyfikator, a nie wielkość liczbowa.
Numer telefonu bardzo często wygląda jak liczba, ale z punktu widzenia informatyki i projektowania baz danych nie jest typową daną liczbową. To identyfikator zapisany jako ciąg znaków o określonym formacie. W tym pytaniu łatwo wpaść w pułapkę myślenia: skoro składa się z cyfr, to typ liczbowy będzie idealny. Tymczasem takie podejście łamie kilka podstawowych zasad modelowania danych. Typ liczbowy służy do przechowywania wartości, na których wykonujemy operacje arytmetyczne: dodawanie, porównywanie zakresów, agregacje. Na numerze telefonu nic takiego się nie robi, więc traktowanie go jako liczby nie ma sensu. Co gorsza, typ liczbowy usuwa wiodące zera, nie pozwala na znak plus na początku, a przy większych długościach może powodować problemy z zakresem. W efekcie tracimy część informacji, czyli dokładne brzmienie numeru, które powinno zostać zapisane tak, jak użytkownik je podał, zgodnie z formatem międzynarodowym. Zdarza się też myślenie, że skoro to tylko sekwencja bitów, to może typ binarny będzie odpowiedni. Typy binarne stosuje się jednak do przechowywania danych niestrukturalnych, takich jak obrazy, pliki PDF, dźwięk, czyli tam, gdzie nie chcemy interpretować zawartości jako tekstu. Numer telefonu ma wyraźnie tekstową reprezentację i często wymaga wyszukiwania po fragmentach, sortowania alfabetycznego czy walidacji wzorców, więc przechowywanie go w formie binarnej tylko utrudni pracę. Pojawia się też czasem pomysł użycia typu wyliczeniowego, ale to kompletnie nie pasuje do danych, które mają ogromną liczbę możliwych wartości i nie są z góry znane. Typ wyliczeniowy sprawdza się przy ograniczonym, zamkniętym zbiorze opcji, jak np. status zamówienia czy płeć w uproszczonym modelu. Dla numerów telefonów, które są dynamiczne, unikalne i praktycznie nieograniczone, taki typ jest niepraktyczny i mija się z celem. Dobra praktyka w projektowaniu baz danych mówi jasno: wszystkie identyfikatory zawierające znaki specjalne, wiodące zera lub formaty zależne od kraju przechowujemy jako tekst z odpowiednią walidacją, a nie jako liczby, binaria czy wyliczenia.