W wielu przypadkach potrzebujemy takich „mniej lub bardziej dokładnych” dat, a ja używam takich dat jak 2011-04-01 (precyzyjne), a także 2011-04 (=kwiecień 2011) i 2011 (data roczna) w metadanych archiwów. Jak o tym wspomniałeś, pole daty MySQL toleruje '2011-00-00', chociaż żadne FAQ nie mówi o tym i jest w porządku.
Ale potem musiałem połączyć MySQL database przez ODBC a pola daty są poprawnie przetłumaczone, z wyjątkiem „tolerowanych” dat (np.:„2011-04-00” w wynikowej bazie danych ACCESS połączonej z MySQL-ODBC jest puste).
Z tego powodu doszedłem do wniosku, że pole daty MySQL można przekonwertować na zwykły VARCHAR(10) field :Tak długo, jak nie potrzebujemy określonych funkcji daty MySQL, działa dobrze i oczywiście nadal możemy używać funkcji daty w php i twojej dobrej funkcji date_php2mysql().
Powiedziałbym, że jedynym przypadkiem, w którym potrzebne jest pole daty MySQL, jest potrzeba złożonych zapytań SQL przy użyciu MySQL data działa w samym zapytaniu.(Ale takie zapytania nie będą już działać w przypadku „mniej lub bardziej precyzyjnych” dat!...)
Wniosek :W przypadku „mniej lub bardziej precyzyjnych” dat, obecnie odrzucam pole daty MySQL i używam zwykłego VARCHAR(10) fieldwith aaaa-mm-jj sformatowane dane. Proste jest piękne.
