कई अवसरों में, हमें ऐसी 'अधिक या कम सटीक' तिथियों की आवश्यकता होती है, और मैं 2011-04-01 जैसी तिथियों का उपयोग करता हूं। (सटीक), साथ ही 2011-04 (=अप्रैल 2011) और 2011 (केवल वर्ष की तारीख) अभिलेखागार मेटाडेटा में। जैसा कि आप इसका उल्लेख करते हैं, MySQL दिनांक फ़ील्ड '2011-00-00' को सहन करता है, हालांकि इसके बारे में कोई अक्सर पूछे जाने वाले प्रश्न नहीं बताते हैं, और यह ठीक है।
लेकिन फिर, मुझे MySQL database को इंटरफ़ेस करना पड़ा। ODBC के माध्यम से और दिनांक फ़ील्ड सही ढंग से अनुवादित हैं, 'सहनशील' तिथियों को छोड़कर (उदा:'2011-04-00' परिणाम परिणामी MySQL-ODBC-कनेक्टेड ACCESS डेटाबेस में खाली हैं।
इस कारण से, मैं इस निष्कर्ष पर पहुंचा कि MySQL दिनांक फ़ील्ड को एक सादे VARCHAR(10) . में परिवर्तित किया जा सकता है फ़ील्ड:जब तक हमें विशिष्ट MySQL दिनांक फ़ंक्शंस की आवश्यकता नहीं है, यह ठीक काम करता है, और निश्चित रूप से, हम अभी भी PHP दिनांक फ़ंक्शंस और आपके ठीक date_php2mysql() फ़ंक्शन का उपयोग कर सकते हैं।
मैं कहूंगा कि केवल एक ही मामला है जब एक MySQL दिनांक फ़ील्ड की आवश्यकता होती है जब किसी को जटिल SQL प्रश्नों की आवश्यकता होती है, MySQL का उपयोग करके दिनांक क्वेरी में ही कार्य करता है। (लेकिन ऐसे प्रश्न 'अधिक या कम सटीक' तिथियों पर काम नहीं करेंगे!...)
निष्कर्ष :'अधिक या कम सटीक' तिथियों के लिए, मैं वर्तमान में MySQL दिनांक फ़ील्ड को त्याग देता हूं और सादा VARCHAR(10) का उपयोग करता हूं फ़ील्डविथ aaaa-mm-jj स्वरूपित डेटा। सरल सुंदर है।
