VARCHAR और DATE/DATETIME

Question

का उपयोग कब करें, इसलिए हमारे पास फ़्रीनोड पर इस प्रोग्रामिंग चर्चा थी और यह प्रश्न तब आया जब मैं इस प्रारूप में दिनांक परिवर्तनीय स्टोर करने के लिए VARCHAR (255) का उपयोग करने का प्रयास कर रहा था: D/MM/YYYY। तो सवाल यह है कि तारीख को स्टोर करने के लिए VARCHAR का उपयोग करना इतना बुरा क्यों है। उसके फायदे हैं:

1. यह कोड के लिए तेज़ है। पहले मैंने DATE का उपयोग किया था, लेकिन डेट स्वरूपण वास्तविक दर्द था।
2. इसकी अधिक शक्ति तिथि से स्ट्रिंग का उपयोग करने के लिए भुखमरी है? कौन परवाह करता है, हम Ghz युग में रहते हैं।
3. इसकी नहीं नैतिकता की दृष्टि से सही (lolwut?) यह वही अन्य उपयोगकर्ता ने मुझे बताया है ...

तो क्या आप एक तिथि स्टोर करने के लिए उपयोग करने के लिए पसंद करेंगे? एसक्यूएल VARCHAR या एसक्यूएल DATE?

Answer 1

आप एक से अधिक 2-3 लाख पंक्तियों के साथ डेटाबेस होगा जब आपको पता चल जाएगा कि ऐसा क्यों VARCHAR :) से DATETIME का उपयोग करने के

सरल जवाब है कि डेटाबेस के साथ है बेहतर है - संसाधन क्षमता एक समस्या नहीं है अब और। बस डेटाबेस का आकार एचडीडी की तलाश के समय के कारण है।

आधुनिक harddisks के साथ मूल रूप से

आप के बारे में 100 रिकॉर्ड पढ़ सकते हैं/सेकंड वे यादृच्छिक क्रम (आमतौर पर मामले) में पढ़ रहे हैं तो आप कम करने के लिए सब कुछ आप कर सकते हैं करना चाहिए डीबी आकार, क्योंकि:

• HDD के सिर करने के लिए "यात्रा" की ज़रूरत नहीं होगी इतना
• आप और अधिक डेटा रैम

में अंत में फिट करेंगे यह हमेशा HDD है की बार है कि तुम्हें मार देंगे चाहते हैं। उदाहरण के लिए। कई पंक्तियों के साथ क्वेरी द्वारा कुछ सरल ग्रुप डिस्क पर किए जाने पर दो सेकंड लग सकते हैं जब खोज समय के कारण RAM => में किए गए कुछ सेकंड की तुलना में।

वर्चर के लिए आप कोई भी खोज नहीं कर सकते हैं। यदि आप इस तरह से नफरत करते हैं कि एसक्यूएल कितने तारीखों से संबंधित है, तो बस 32 बिट पूर्णांक फ़ील्ड में यूनिक्स टाइमस्टैम्प का उपयोग करें। आपके पास SQL ​​DATE फ़ील्ड का उपयोग करने के सभी फायदे होंगे (मूल रूप से), आपको बस अपनी चुनी प्रोग्रामिंग भाषा का उपयोग करके तिथियों में हेरफेर और प्रारूप करना होगा, एसक्यूएल फ़ंक्शंस नहीं।

Answer 2

दो कारण हैं: दिनांक

तिथि स्वरूपण के प्रति संवेदनशील नहीं द्वारा

• परिणाम छंटाई में परिवर्तन

तो चलो उदाहरण के लिए अभिलेखों का एक सेट है कि इस तरह दिखता है डालें:

5/12/1999 | Frank N Stein 
1/22/2005 | Drake U. La 
10/4/1962 | Goul Friend 

यदि हम डेटा को आपके तरीके से स्टोर करना चाहते थे, लेकिन ओ में सहायता करने के लिए तारीखों को क्रमबद्ध किया गया था rder एसक्यूएल resultset कि इस तरह दिखता है के साथ जवाब देंगे:

1/22/2005 | Drake U. La 
10/4/1962 | Goul Friend 
5/12/1999 | Frank N. Stein 

कहाँ अगर हम एक DATETIME के ​​रूप में दिनांक संग्रहीत, एसक्यूएल सही ढंग से जवाब देंगे इस तरह से उन्हें आदेश देने:

10/4/1962 | Goul Friend 
5/12/1999 | Frank N. Stein 
1/22/2005 | Drake U. La 

साथ ही, यदि कहीं नीचे जिस सड़क को आपको एक अलग प्रारूप में दिनांक प्रदर्शित करने के लिए जरूरी है, उदाहरण के लिए YYYY-MM-DD, तो आपको अपने सभी डेटा को बदलने या मिश्रित सामग्री से निपटने की आवश्यकता होगी। जब इसे SQL DATE के रूप में संग्रहीत किया जाता है, तो आपको कोड में रूपांतरण करने के लिए मजबूर होना पड़ता है, और संभवतः सभी तिथियों को प्रदर्शित करने के लिए प्रारूप को बदलने के लिए एक स्थान होता है - मुफ्त में।

Answer 3

हथौड़ा के साथ शिकंजा क्यों नहीं डालें?

क्योंकि यह नौकरी के लिए सही उपकरण नहीं है।

VARCHAR संस्करण का नुकसान में से कुछ:

• आप आसानी से VARCHAR संस्करण में नहीं जोड़ सकते हैं/दिन घटाना।
• केवल महीने/वर्ष निकालना मुश्किल है।
• डेटाबेस में VARCHAR कॉलम में गैर-दिनांक डेटा डालने से आपको कुछ भी रोक नहीं है।
• VARCHAR संस्करण संस्कृति विशिष्ट है।
• आप आसानी से तिथियों को सॉर्ट नहीं कर सकते हैं।
• यदि आप बाद में चाहते हैं तो प्रारूप को बदलना मुश्किल है।
• यह अपरंपरागत है, जो अन्य डेवलपर्स को समझने के लिए कठिन बना देगा।
• कई वातावरण में, VARCHAR का उपयोग करके अधिक संग्रहण स्थान का उपयोग किया जाएगा। यह डेटा की थोड़ी मात्रा के लिए कोई फर्क नहीं पड़ता है, लेकिन डेटा के लाखों पंक्तियों के साथ वाणिज्यिक वातावरण में यह एक बड़ा अंतर बना सकता है।

बेशक, अपने शौक परियोजनाओं में आप जो भी चाहते हैं वह कर सकते हैं। एक पेशेवर वातावरण में मैं नौकरी के लिए सही उपकरण का उपयोग करने पर जोर देता हूं।

Answer 4

DATE/DATETIME और VARCHAR के बीच दिनांक के लिए मैं DATE/DATETIME के साथ हर बार जाऊंगा। लेकिन एक अनदेखा तीसरा विकल्प है। इसे एक इंटेग्रर के रूप में संग्रहीत किया गया है!

मैंने अपने पिछले प्रोजेक्ट में INTEGER unsigned के साथ जाने का फैसला किया, और मैं इसे DATE/DATETIME के रूप में संग्रहीत करने के बजाय उस विकल्प को बनाने से वास्तव में संतुष्ट हूं। क्योंकि मैं क्लाइंट और सर्वर के बीच की तिथियों के साथ गुज़र रहा था क्योंकि यह मेरे लिए उपयोग करने के लिए आदर्श प्रकार बना। इसे DATE के रूप में स्टोर करने के बजाय और हर बार जब मैं चयन करता हूं, तो उसे वापस परिवर्तित करने के बजाय, मैं बस इसे चुनता हूं और इसका उपयोग करता हूं हालांकि मैं इसे चाहता हूं। यदि आप दिनांक को "मानव-पठनीय" तिथि के रूप में चुनना चाहते हैं तो आप FROM_UNIXTIME() फ़ंक्शन का उपयोग कर सकते हैं।

इसके अलावा एक पूर्णांक 4 बाइट लेता है जबकि DATETIME 8 बाइट लेता है। 50% भंडारण बचा रहा है।

बेरिन प्रस्तावित सॉर्टिंग समस्या को भी तारीखों के लिए भंडारण के रूप में पूर्णांक का उपयोग करके हल किया जाता है।

Answer 5

मैं सादगी/स्थिरता के लिए दिनांक/डेटाटाइम प्रकारों का उपयोग करने के लिए वोट दूंगा।

आप एक चरित्र स्ट्रिंग के रूप में संग्रहीत ISO 8601 प्रारूप में संग्रहीत करते हैं:, आईएसओ 8601 दिनांक/समय

• http://www.iso.org/iso/date_and_time_format
• http://xml.coverpages.org/ISO-FDIS-8601.pdf
• http://www.cl.cam.ac.uk/~mgk25/iso-time.html

अन्य बातों के अलावा स्ट्रिंग (ए) सही ढंग से collate, (बी) मानव पठनीय हैं, (सी) लोकेल-इंडिपेंडेंट हैं, और (डी) अन्य प्रारूपों में आसानी से परिवर्तनीय हैं।

• दिनांक
• दिन
• समन्वित यूनिवर्सल समय (UTC)
• स्थानीय समय के समय: आईएसओ blurb से पालना करने के लिए, आईएसओ 8601 तार निम्नलिखित के लिए

  अभ्यावेदन की पेशकश यूटीसी

• दिनांक और समय
• समय अंतराल
• आवर्ती समय अंतराल

दो स्वरूपों में से एक में

प्रतिनिधित्व किया जा सकता है: एक बुनियादी प्रारूप वर्णों की एक न्यूनतम संख्या और एक विस्तारित प्रारूप कि मानव पठनीयता को बढ़ाने के लिए पात्रों कहते है। उदाहरण के लिए, जनवरी 2003 का तीसरा 20030103 या 2003-01-03 के रूप में प्रदर्शित किया जा सकता है।

[और]

प्रस्ताव स्थानीय स्तर के कई से अधिक निम्न लाभ निरूपण का उपयोग किया:

• आसानी से पठनीय और प्रणालियों
• आसानी से तुलनीय और sortable
• भाषा स्वतंत्र
द्वारा लिखने योग्य
• बड़ी इकाइयों के सामने बड़ी इकाइयां लिखी जाती हैं
• सबसे अभ्यावेदन के लिए अंकन कम और निरंतर लंबाई का है

एक आखिरी बात: अगर तुम सब करने की जरूरत है एक तारीख की दुकान है, तो एक चार में 8601 लघु रूप YYYYMMDD आईएसओ में भंडारण है (8) कॉलम डेटाटाइम वैल्यू से अधिक स्टोरेज नहीं लेता है (और आपको एक दिन के अंतिम टिक और अगले के पहले टिक के बीच 3 मिलीसेकंद अंतर के बारे में चिंता करने की आवश्यकता नहीं है। लेकिन यह एक और चर्चा के लिए एक मामला है। यदि आप इसे 3 कॉलम — YYYY char(4), MM char(2), DD char(2) में विभाजित करते हैं तो आप उसी मात्रा में संग्रहण का उपयोग करेंगे, और अनुक्रमण के लिए और विकल्प प्राप्त करेंगे। इससे भी बेहतर, फ़ील्ड को yyyy (4 बाइट्स) के लिए छोटा, और प्रत्येक एमएम और डीडी — के लिए एक छोटा सा स्टोर स्टोर करें, अब आप तिथि के लिए 6 बाइट्स तक नीचे हैं। निश्चित रूप से, दोष घटकों को उनके घटक भागों में विघटित करने के लिए यह है कि उचित दिनांक/समय डेटा प्रकारों में रूपांतरण जटिल है।