Zakres:
Zawsze istnieje oczywista wada:zakres, który możesz przechowywać, jest ograniczony od 1970 do 2038 r. Jeśli chcesz przechowywać daty spoza tego zakresu, zazwyczaj będziesz musiał użyć innego formatu. Najczęstszym przypadkiem, który znalazłem, jest to, że dotyczy to dat urodzin.
Czytelność:
Myślę, że najważniejszym powodem, dla którego ludzie wybrali jeden z wbudowanych typów dat, jest to, że dane są łatwiejsze do interpretacji. Możesz dokonać prostego wyboru i zrozumieć wartości bez konieczności dalszego formatowania odpowiedzi.
Indeksy:
Dobrym technicznym powodem używania typów dat jest to, że pozwalają one na indeksowanie zapytań w niektórych przypadkach, których nie umożliwiają uniksowe sygnatury czasowe. Rozważ następujące zapytanie:
SELECT * FROM tbl WHERE year(mydate_field) = 2009;
Jeśli mydate_field jest natywnym typem daty i w polu znajduje się indeks, to zapytanie faktycznie użyje indeksu, pomimo wywołania funkcji. To prawie jedyny przypadek, kiedy mysql może zoptymalizować wywołania funkcji w polach takich jak to. Odpowiednie zapytanie w polu znacznika czasu nie będzie mogło używać indeksów:
SELECT * FROM tbl WHERE year(from_unixtime(mytimestamp_field)) = 2009;
Jeśli zastanowisz się nad tym przez chwilę, jest jednak sposób na obejście tego. To zapytanie robi to samo, a będzie móc korzystać z optymalizacji indeksów:
SELECT * FROM tbl WHERE mytimestamp_field > unix_timestamp("2009-01-01") AND mytimestamp_field < unix_timestamp("2010-01-01");
Obliczenia:
Generalnie przechowuję daty jako czas uniksowy, pomimo wad. To nie jest tak naprawdę oparte na jego zaletach, ale raczej dlatego, że jestem do tego przyzwyczajony. Odkryłem, że to upraszcza niektóre obliczenia, ale komplikuje inne. Na przykład bardzo trudno jest dodać miesiąc do znacznika czasu uniksowego, ponieważ liczba sekund na miesiąc jest różna. Jest to bardzo proste przy użyciu funkcji mysql DATE_ADD(). Myślę jednak, że w większości przypadków faktycznie upraszcza to obliczenia. Na przykład dość często chcesz wybrać posty z, powiedzmy, ostatnich dwóch dni. Jeśli pole zawiera uniksowy znacznik czasu, można to łatwo zrobić, po prostu wykonując:
SELECT * FROM tbl WHERE mytimestamp_field > time() - 2*24*3600;
To prawdopodobnie kwestia gustu, ale osobiście uważam to za szybsze i łatwiejsze niż pamiętanie składni funkcji takiej jak DATE_SUB().
Strefy czasowe:
Sygnatury czasowe Unix nie mogą przechowywać danych o strefach czasowych. Mieszkam w Szwecji, która ma jedną strefę czasową, więc nie stanowi to dla mnie problemu. Jednak może to być poważnym problemem, jeśli mieszkasz w kraju, który obejmuje wiele stref czasowych.
