Trong nhiều trường hợp, chúng tôi cần những ngày 'chính xác hơn hoặc ít chính xác hơn' và tôi sử dụng những ngày như vậy 2011-04-01 (chính xác), cũng như 2011-04 (=Tháng 4 năm 2011) và 2011 (ngày chỉ trong năm) trong siêu dữ liệu lưu trữ. Như bạn đã đề cập, trường ngày tháng của MySQL chịu đựng '2011-00-00' mặc dù không có Câu hỏi thường gặp nào nói về nó và nó ổn.
Nhưng sau đó, tôi phải giao diện với MySQL database qua ODBC và các trường ngày tháng được dịch chính xác, ngoại trừ các ngày 'được dung nạp' (Ví dụ:'2011-04-00' kết quả trống trong cơ sở dữ liệu ACCESS được kết nối với MySQL-ODBC.
Vì lý do đó, tôi đã đi đến kết luận rằng trường ngày MySQL có thể được chuyển đổi thành VARCHAR(10) đơn giản field:Miễn là chúng ta không cần các hàm date MySQL cụ thể, nó hoạt động tốt và tất nhiên, chúng ta vẫn có thể sử dụng các hàm date php và hàm date_php2mysql () tốt của bạn.
Tôi sẽ nói rằng trường hợp duy nhất khi trường ngày MySQL là cần thiết là khi một người cần các truy vấn SQL phức tạp, sử dụng MySQL các hàm ngày trong chính truy vấn. (Nhưng các truy vấn như vậy sẽ không hoạt động nữa vào những ngày 'chính xác hơn hoặc ít chính xác hơn'! ...)
Kết luận :Đối với các ngày 'chính xác hơn hoặc ít chính xác hơn', hiện tại tôi loại bỏ trường ngày MySQL và sử dụng VARCHAR(10) đơn giản fieldwith aaaa-mm-jj dữ liệu định dạng. Đơn giản là đẹp.
