Baza danych - pierwsza tabelka

Kolejną rzeczą, jaką chciałam się zająć po wprowadzeniu (działającej!) formatki logowania, była funkcja zapamiętywania zalogowanego użytkownika - wszak mam taki śliczny checkbox "Remember me". :) Rzeczywistość po raz kolejny jednak brutalnie zweryfikowała moje plany, bo do tej funkcjonalności będę potrzebowała bazy danych. Logiczne, przecież gdzieś trzeba zapisać, kto chce być zapamiętany, czyż nie?
Na razie porzucam więc HTMLe i CSSy na rzecz bardziej backendowych zadań. Najwyższy czas dołączyć do projektu bazę danych. No bo co to za aplikacja bez bazy?


Zdecydowałam się na silnik MySQL - głównie ze względu na popularność. I tak w tym tygodniu powstała wreszcie pierwsza tabelka:

create table Users (
    usr_id int not null auto_increment primary key,
    usr_first_name nvarchar(100),
    usr_last_name nvarchar(100),
    usr_login nvarchar(100),
    usr_pass nvarchar(100),
    usr_birth_date date,
    usr_status char(1),
    usr_remember_me bool,
    usr_token varchar(100),
    usr_token_validity datetime
);

Osobiście uważam, że czas poświęcony na wyprodukowanie tych kilku linii kodu był niewspółmierny do efektów. Modliłam się nad każdą linijką niebotycznie długo, szperałam w internecie, szukałam najlepszych rozwiązań - a to bo trzeba klucz, a to jakiego typu danych użyć - wszystko po to, żeby była idealna.
No i przyznaję, że jestem z niej całkiem zadowolona.
Ważna rzecz, której się przy tym nauczyłam to różnica między poszczególnymi typami przechowującymi ciągi znaków. Mamy w SQL 4 typy przechowujące dane typu String, które czasem są ze sobą (niesłusznie) utożsamiane: char, nchar, varchar i nvarchar. Szerzej na temat ich wad i zalet można poczytać tutaj, ja ograniczę się do krótkiego podsumowania różnic między nimi:

• char i nchar - to typy o stałej długości. Niezależnie więc od tego, czy przechowujemy ciąg "abc" czy "abcde", char(5) zajmie w pamięci tyle samo miejsca.
• varchar i nvarchar - to typy o zmiennej długości. Oznacza to, że "abc" zajmie w pamięci mniej miejsca niż "abcde", gdy kolumna jest typu varchar(5).
• przedrostek n (nchar i nvarchar) oznacza, że znaki kodowane są w Unicode - w takiej kolumnie możemy oprócz znaków łacińskich zapisać także znaki z innych alfabetów, np. cyrylicy czy alfabetu arabskiego. Ma to jednak swoją wadę - nchar zajmuje w pamięci 2 razy więcej miejsca niż char.

Znając powyższe różnice, podjęłam takie a nie inne decyzje przy ustalaniu typów kolumn w mojej idealnej tabelce. Dlatego na przykład kolumna usr_status jest typu char(1) - bo wiem, że będę przechowywać jednoznakowy kod statusu; nie potrzebuję do tego ani zmiennej długości pola (varchar), ani Unicode (nchar). Wybrałam więc najmniejszy możliwy rozmiar tej kolumny. Imię i nazwisko użytkownika jest typu nvarchar, podobnie jak login i hasło - tu miałam wątpliwości, czy na pewno tego potrzebuję, ale może warto zostawić sobie taką furtkę. Kto wie, może osiągnę międzynarodowy sukces i moi użytkownicy będą używali innych alfabetów niż łacińskiego? Haha. Tak czy inaczej, podobnego problemu nie miałam z polem usr_token - ma ono przechowywać token potrzebny przy funkcjonalności "remember me", a takiemu tokenowi z pewnością wystarczy stary dobry łaciński alfabet.
Cóż, nie ma się tu co za mocno rozpisywać. Mam nadzieję, że jutro uda mi się podpiąć bazę do projektu i być może nawet zaprogramować pamiętanie zalogowanego użytkownika. Trzymajcie kciuki!