मेरे डेटाबेस के डेट डेटाइप क्रूसेड के बारे में: मान्य? सार्थक? क्या कोई और इसे महसूस करता है?

13

मैं एसओ पर एसक्यूएल सवालों के जवाब देने में बहुत समय बिताता हूं। मैं अक्सर इस ilk के प्रश्नों पर आता हूँ:

SELECT * FROM person WHERE birthdate BETWEEN '01/01/2017' AND '01/03/2017'

SELECT * FROM person WHERE birthdate BETWEEN '2017-01-01' AND '2017-03-01'

SELECT * FROM person WHERE birthdate BETWEEN 'some string' AND 'other string'

यानी या तो दिए गए मापदंडों के स्ट्रिंग से तारीख (खराब) पर निहित रूपांतरण पर निर्भर है, या डेटाबेस पर निर्भर x मिलियन डेटाबेस पंक्ति मानों को स्ट्रिंग करने और स्ट्रिंग तुलना (बदतर) करने के लिए

मैं कभी-कभी एक टिप्पणी करता हूं, खासकर अगर यह एक उच्च प्रतिनिधि उपयोगकर्ता है जो एक स्मार्ट उत्तर लिखता है, लेकिन जिन्हें मैं वास्तव में महसूस करता हूं उन्हें कम मैला / कड़ाई से उनके डेटा प्रकारों के साथ टाइप किया जाना चाहिए

टिप्पणी आमतौर पर यह रूप लेती है कि यह शायद बेहतर होगा यदि वे स्पष्ट रूप से अपने तार को तारीखों में बदल दें, to_date (Oracle), str_to_date (MySQL), कन्वर्ट (SQLSERVER) या कुछ समान तंत्र का उपयोग कर:

    --oracle
    SELECT * FROM person WHERE birthdate BETWEEN TO_DATE('20170101', 'YYYYMMDD') AND TO_DATE('20170301', 'YYYYMMDD')

    --mysql
    SELECT * FROM person WHERE birthdate BETWEEN STR_TO_DATE('20170101', '%Y%m%d') AND STR_TO_DATE('20170301', '%Y%m%d')

    --SQLS, ugh; magic numbers
    SELECT * FROM person WHERE birthdate BETWEEN CONVERT(datetime, '20170101', 112) AND CONVERT(datetime, '20170301', 112)

ऐसा करने के लिए मेरा तकनीकी औचित्य यह है कि यह तारीख के प्रारूप के रूप में स्पष्ट है, और यह सुनिश्चित करता है कि कुछ स्रोत पैरामीटर निश्चित रूप से लक्ष्य स्तंभ का डेटाटाइप बन सकते हैं। यह किसी भी संभावना को रोकता है कि डेटाबेस को एक अंतर्निहित रूपांतरण गलत मिलेगा (बहुत पहले उदाहरण के 3 जनवरी / 1 मार्च तर्क) और यह डीबी को तालिका में एक लाख दिनांक मानों को स्ट्रिंग में बदलने का निर्णय लेने से रोकता है (कुछ सर्वर विशिष्ट तिथि का उपयोग करके) तुलना करने के लिए प्रारूपण स्ट्रिंग वर्ग में तारीख मानकों के प्रारूप से मेल नहीं खा सकता है) - भयावह घाव

ऐसा करने के लिए मेरा सामाजिक / शैक्षणिक औचित्य यह है कि एसओ एक सीखने की जगह है; इस पर लोग या तो स्पष्ट रूप से या स्पष्ट रूप से ज्ञान प्राप्त करते हैं। उत्तर के रूप में इस क्वेरी के साथ एक नौसिखिया हिट करने के लिए:

SELECT * FROM person WHERE birthdate BETWEEN '2017-01-01' AND '2017-03-01'

उन्हें यह सोचने के लिए प्रेरित कर सकता है कि यह समझदार है, कुछ प्रारूप के लिए तारीख को समायोजित करना जो वे पसंद करते हैं:

SELECT * FROM person WHERE birthdate BETWEEN '01/01/2017' AND '01/03/2017'

यदि उन्होंने तिथि को परिवर्तित करने के लिए कम से कम कुछ स्पष्ट प्रयास देखे, तो वे इसे अपने अजीब तिथि प्रारूप के लिए करना शुरू कर सकते हैं, और कुछ उठने से पहले उन्हें हमेशा के लिए मार सकते हैं। आखिरकार, हम (आई) लोगों को एसक्यूएल इंजेक्शन की आदत में शामिल होने से रोकते हैं और उन्हें रोकते हैं (और क्या कोई क्वेरी की वकालत कर सकता है और फिर ड्राइवर को घोषित कर सकता है कि @pBirthdateयह एक स्ट्रिंग है, जब फ्रंटेंड में डेटाइम प्रकार है?)

मेरी सिफारिश करने के बाद क्या होता है: मुझे आमतौर पर "स्पष्ट होना, एक्स का उपयोग करना" जैसी कुछ सिफारिशें मिलती हैं, जैसे "हर कोई इसे करता है", "यह हमेशा मेरे लिए काम करता है", "मुझे कुछ मैनुअल या संदर्भ डॉक्टर दिखाएं यह कहता है कि मुझे स्पष्ट होना चाहिए "या" क्या ?? "

मैंने इनमें से कुछ के जवाब में पूछा है कि क्या वे WHERE age = '99'एक स्ट्रिंग के रूप में उम्र को पार करके एक अंतर स्तंभ की खोज करेंगे। "मूर्ख मत बनो, हमें 'int खोजते समय' डालने की आवश्यकता नहीं है" प्रतिक्रिया आती है, इसलिए उनके दिमाग में कहीं न कहीं विभिन्न डेटा प्रकारों के लिए कुछ प्रशंसा होती है, लेकिन शायद तार्किक छलांग के लिए कोई संबंध नहीं है जो एक इंट की खोज कर रहा है एक स्ट्रिंग (जाहिरा तौर पर मूर्खतापूर्ण) पास करके और एक स्ट्रिंग (जाहिरा तौर पर समझदार) पास करके एक तारीख स्तंभ की खोज करना पाखंड है

इसलिए हमारी एसक्यूएल में हमारे पास चीजों को संख्याओं के रूप में लिखने का एक तरीका है (संख्याओं का उपयोग करें, बिना सीमांकक के), स्ट्रिंग स्ट्रिंग्स के रूप में चीजें (एपोस्ट्रोफी डेलिमिटर के बीच कुछ भी उपयोग करें) .. तारीखों के लिए कोई सीमांकक क्यों नहीं? यह अधिकांश डीबी में ऐसा मौलिक डेटा प्रकार है? क्या यह पूरी बात शायद हल हो सकती है जिस तरह से एक तारीख लिखने का एक तरीका है, उसी तरह से जावास्क्रिप्ट हमें /कुछ वर्णों के दोनों ओर लगाकर एक रीजेक्स निर्दिष्ट करने देता है । /Hello\s+world/। तारीखों के लिए कुछ क्यों नहीं है?

वास्तव में, मेरे ज्ञान के लिए, (केवल) Microsoft Access में वास्तव में प्रतीक हैं जो इंगित करते हैं कि "इन सीमांकक के बीच एक तारीख लिखी गई है" इसलिए हम एक अच्छा शॉर्टकट प्राप्त कर सकते हैं, WHERE datecolumn = #somedate#लेकिन दिनांक प्रस्तुति अभी भी समस्याओं को देने के लिए उत्तरदायी है जैसे mm / di बनाम dd / एमएम, क्योंकि एमएस ने हमेशा तेजी से और ढीले खेले हैं और वीबी भीड़ के सामान के साथ एक अच्छा विचार था

मुख्य बिंदु पर वापस: मैं तर्क दे रहा हूं कि इस माध्यम से स्पष्ट होना बुद्धिमानी है जो हमें विभिन्न डेटाटाइप्स की एक स्ट्रिंग्स के रूप में पारित करने के लिए मजबूर करता है ।।

क्या यह वैध दावा है?

क्या मुझे यह धर्मयुद्ध जारी रखना चाहिए? क्या यह एक वैध बिंदु है कि सख्ती से टाइप करना आधुनिक नहीं-नहीं है? या क्या हर आरडीबीएमएस (प्राचीन संस्करणों सहित) वहां से बाहर निकलता है, जब एक क्वेरी जोर से WHERE datecolumn = 'string value'निश्चित रूप से सही ढंग से स्ट्रिंग को एक तिथि में परिवर्तित करती है और तालिका डेटा को परिवर्तित किए बिना खोज करती है / अनुक्रमित का उपयोग खो रही है? मुझे संदेह है कि कम से कम ओरेकल के व्यक्तिगत अनुभव से 9. मुझे यह भी संदेह है कि कुछ दूर-दूर के परिदृश्य हो सकते हैं यदि तार हमेशा कुछ आईएसओ मानक प्रारूप में लिखे जाते हैं, और कॉलम कुछ दिनांक स्वाद है, तो स्ट्रिंग पैरामीटर हमेशा सही ढंग से अंतर्निहित रूप से रूपांतरित होगा। क्या यह सही है?

क्या यह एक सार्थक कार्य है?

बहुत से लोग इसे प्राप्त नहीं करते हैं, या इसकी परवाह नहीं करते हैं, या कुछ पाखंड का प्रदर्शन करते हैं कि उनके पैर की उंगलियों में छेद हैं, लेकिन उनकी तारीखें तार हैं .. आम तौर पर हालांकि कुछ लोगों ने कभी चक्कर लगाया और कहा कि "आप जानते हैं" क्या, मैं आपकी बात से सहमत हूं। मुझे अब से अपनी तारीखों के बारे में स्पष्ट हो जाएगा।

sql data-types date-format

— कयूस जर्द
स्रोत

मैंने यहां तक कि किसी को WHERE datecolumn = 01/02 / 12'` के साथ समस्याओं को देखा है, जहां यह संभव है कि वे वर्ष 1912, 2012, 2001, 1901, 12 या 1. के लिए पूछ रहे हैं। यह डेटाबेस की दुनिया के बाहर भी एक समस्या है, संख्या प्रोग्रामर जो समझ नहीं पा रहे हैं कि "09"इंट में कन्वर्ट होने के कारण दुर्घटना क्यों होती है, लीजन 9

— स्टीव बार्न्स

2

मैंने यह पूछने के लिए अपने उदाहरण का विस्तार करने के बारे में सोचा कि क्या WHERE age = '0x0F'एक उम्मीद है कि एक डेटाबेस पंद्रह साल के बच्चों की खोज करेगा।

— कैयुस जार्ड

1

मैंने एक प्रश्न को हटा दिया है जो यहाँ ऑफ टॉपिक है - हम संसाधन अनुरोध नहीं करते हैं। 2 करीबी वोटों में से एक इस कारण से दिया गया था। अन्यथा, मुझे लगता है कि यह एक वैध प्रश्न है, हालांकि यह बहुत व्यापक होने पर सीमा हो सकती है। मुझे उम्मीद है कि ऑफ-टॉपिक प्रश्न को हटाने से चीजों को थोड़ा कम करने में मदद मिलती है।

— थॉमस ओवेन्स

टीएल; डीआर लेकिन उत्पादन प्रणालियों में, मैं इस तरह की तारीखों की अपेक्षा करता हूं जो लगभग हमेशा मापदंडों में होती हैं। प्रश्नों में हार्डकोडिंग की तारीखें एक बड़ी समस्या है कि क्या आप निहित रूपांतरणों का उपयोग करते हैं। अगर मैं कुछ फेंक क्वेरी लिख रहा हूँ, यह या तो काम करता है या यह नहीं है। मैं कभी भी ऐसा नहीं करता (क्योंकि मैं डिफ़ॉल्ट तिथि प्रारूप को कभी याद नहीं रख सकता) लेकिन मुझे यकीन नहीं है कि यह बहुत मायने रखता है।

— जिमीजम्स

1

जिंदगी अपनी लड़ाइयों को चुनने के बारे में है। मेरे विचार में, यह सिर्फ लड़ने के लायक नहीं है ...

— रोबी डी

7

आप ने लिखा:

उन मापदंडों 1 जनवरी से 3 जनवरी, या 1 मार्च ..

यह वास्तव में त्रुटियों का एक संभावित स्रोत है। यह पूछने वाले को इंगित करना अन्य पाठकों के लिए उपयोगी हो सकता है, इसलिए हां, यह एक वैध चिंता है। हालांकि, रचनात्मक होने के लिए, मैं करूंगा

ANSI SQL का संदर्भ लें और उस मानक से DATE या DATETIME शाब्दिक का उपयोग करें
एक विशिष्ट DBMS के सामान्य, असंदिग्ध डेटाटाइम प्रारूप का उपयोग करें (और उल्लेख करें कि कौन सी एसक्यूएल बोली का उपयोग किया जाता है)

दुर्भाग्य से, प्रत्येक DBMS बिल्कुल उसी तरह से ANSI SQL तिथि शाब्दिक का समर्थन नहीं करता है (यदि वे इसे बिल्कुल समर्थन करते हैं), तो यह आम तौर पर दूसरे दृष्टिकोण के एक संस्करण का कारण होगा। तथ्य "मानक" अलग-अलग DB विक्रेताओं द्वारा कठोरता से लागू नहीं किया गया है, शायद यहाँ समस्या का हिस्सा है।

आगे ध्यान दें, कई वास्तविक दुनिया प्रणालियों के लिए, लोग वास्तव में डेटाबेस सर्वर पर एक विशिष्ट, निश्चित स्थान पर भरोसा कर सकते हैं, भले ही क्लाइंट अनुप्रयोग स्थानीयकृत हों, क्योंकि बस एक तरह का सर्वर है, हमेशा उसी तरह से कॉन्फ़िगर किया गया है। इसलिए '01 / 03/2017 'को प्रायः उन विशिष्ट सिस्टम पर उपयोग किए जाने वाले किसी भी SQL के लिए निश्चित प्रारूप' dd / mm / yyyy ', या' mm / dd / yyyy 'माना जा सकता है, जिसके साथ वे काम कर रहे हैं। इसलिए अगर कोई आपसे कहे "यह हमेशा मेरे लिए काम करता है", तो यह वास्तव में उसके पर्यावरण के लिए एक समझदार उत्तर होगा । यदि यह मामला है, तो यह इस विषय पर चर्चा करने के लिए कम योग्य बनाता है।

"प्रदर्शन कारणों" के बारे में बात करना: जब तक कोई औसत दर्जे का प्रदर्शन समस्याएं नहीं होती हैं, यह "संभावित प्रदर्शन मुद्दों" के साथ बहस करने के लिए काफी अंधविश्वास है। यदि डेटाबेस एक मिलियन स्ट्रिंग-टू-डेट रूपांतरण कर रहा है या नहीं, तो इससे कोई फर्क नहीं पड़ता कि समय अंतर केवल 1/1000 सेकंड है, और असली अड़चन वह नेटवर्क है जो क्वेरी को 10 सेकंड तक ले जाता है। तो बेहतर है कि इन चिंताओं को एक तरफ रखें जब तक कि कोई व्यक्ति प्रदर्शन के लिए स्पष्ट रूप से पूछता है।

क्या मुझे यह धर्मयुद्ध जारी रखना चाहिए?

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

— डॉक्टर ब्राउन
स्रोत

यह हालांकि अमेरिकी बनाम समझदार तारीख प्रारूपों की अस्पष्टता के बारे में इतना सवाल नहीं है। यह एक स्ट्रिंग के रूप में एक एसक्यूएल बयान में तारीखों को पास करने के लिए समझदार है या नहीं, इसके बारे में तारीख के लिए अंतर्निहित रूपांतरण पर निर्भर है। डेटाबेस का सवाल एक मिलियन डेट करने के लिए -> सभी मिलियन रो के लिए स्ट्रॉग रूपांतरण एक प्रदर्शन का पहलू है, और इसमें एक क्वेरी के लिए सेकंड का केवल 1/1000 वां हिस्सा लग सकता है, लेकिन अब इसे समवर्ती के नतीजों के संदर्भ में कल्पना करें उपयोगकर्ताओं। बड़ा प्रदर्शन मुद्दा यह है कि डेटा को परिवर्तित करने का अर्थ है कि अनुक्रमित का अब उपयोग नहीं किया जा सकता है और यह वास्तव में गंभीर हो सकता है

— कायुस जार्ड

@ काईसजार्ड: मेरा जवाब खड़ा है: यह कभी-कभी समझदार होता है, और कभी-कभी नहीं, यह संदर्भ पर निर्भर करता है। और ईमानदारी से, मैं यहां ... "कल्पना ..." कुछ भी करने से इनकार करता हूं । जब प्रदर्शन की बात आती है, तो किसी भी काल्पनिक मामले पर चर्चा करना उपयोगी नहीं होता है। जब औसत दर्जे का प्रदर्शन के मुद्दे होते हैं, तो यह अनुकूलन करने का समय होता है, और कभी-कभी माइक्रो-ऑप्टिमाइज़ करने के लिए, पहले से नहीं।

— डॉक ब्राउन

यह दिलचस्प है कि आप इसे काल्पनिक के रूप में देखते हैं; मुझे लगता है कि कीड़े और प्रदर्शन की जटिलताओं के लिए स्पष्ट अवसर के रूप में निहित व्यवहार पर भरोसा करना (अच्छी तरह से प्रलेखित कारणों के लिए: अनुक्रमित काम नहीं करता है यदि संपूर्ण स्तंभ डेटा को खोजे जाने से पहले बदल दिया जाता है), और स्पष्ट निर्देशों के साथ ऐसा नहीं हो सकता है

— कैयस Jard

@CaiusJard: शब्दों के साथ मत खेलो - "काल्पनिक" से मेरा मतलब "असंभावित" नहीं है, मैंने किसी भी तरह के कल्पना परिदृश्य के लिए इस शब्द का इस्तेमाल किया, "वास्तविक मौजूदा स्थिति" के विपरीत जहां कोई भी माप सकता है कि क्या होता है।

— डॉक ब्राउन

1

@CaiusJard: यदि आप अन्य उद्योग पेशेवरों को प्रभावित करना चाहते हैं, तो आपको ठीक से पता होना चाहिए कि "प्रदर्शन अनुकूलन" "सुरक्षा अनुकूलन" से बहुत अलग क्यों है, और यह बिल्कुल मेरी बात यहाँ है - प्रदर्शन के मुद्दों को उनके होने के बाद संभाला जा सकता है, जो शायद ही कभी होता है बहुत देर। सुरक्षा के मुद्दे, उन्हें होने से पहले पूरी तरह से बचा जाना चाहिए। तो कृपया संतरे के साथ सेब की तुलना न करें। आप तो धर्मयुद्ध की तरह, सुरक्षा तर्क काफी बेहतर इस के लिए ;-) अनुकूल हैं

— डॉक ब्राउन

5

आपका धर्मयुद्ध समस्या का समाधान नहीं करता है।

दो अलग-अलग मुद्दे हैं:

SQL में निहित प्रकार रूपांतरण
05/06/07 की तरह अस्पष्ट तिथि प्रारूप

मैं देखता हूं कि आप अपने धर्मयुद्ध के साथ कहां से आ रहे हैं, लेकिन मुझे नहीं लगता कि स्पष्ट रूपांतरण वास्तव में समस्या को हल करता है:

तुलना में प्रकारों के बीच एक बेमेल के मामले में अभी भी निहित रूपांतरण होता है। यदि किसी तार की तुलना किसी दिनांक से की जाती है, तो SQL स्ट्रिंग को पहले दिनांक में परिवर्तित करने का प्रयास करेगा। इसलिए तिथि-प्रकार के कॉलम की तुलना स्पष्ट रूप से परिवर्तित दिनांक मान से करना बिल्कुल वैसा ही है जैसा कि स्ट्रिंग-प्रारूप में दिनांक की तुलना करना। केवल इतना ही अंतर मुझे दिखाई देता है कि यदि आप किसी दिनांक मान की तुलना उस स्तंभ से करते हैं जिसमें वास्तव में दिनांक नहीं हैं, लेकिन तार हैं - लेकिन यह किसी भी स्थिति में एक त्रुटि होगी।
स्पष्ट रूपांतरण का उपयोग गैर-आईएसओ दिनांक स्वरूपों में अस्पष्टता को हल नहीं करता है।

एकमात्र समाधान जो मैं देख रहा हूं:

स्ट्रिंग-प्रकार के स्तंभों की गैर-स्ट्रिंग मानों से तुलना न करें।
केवल कभी आईएसओ प्रकार दिनांक स्वरूपों का उपयोग करें।

और हां, कभी स्ट्रिंग-टाइप कॉलम में तारीखों को संग्रहीत न करें। लेकिन फिर से, तारीख शाब्दिक के स्पष्ट रूपांतरण से इसे रोका नहीं जा सकेगा।

तर्क से, निहित रूपांतरण SQL में एक गलती थी, लेकिन यह देखते हुए कि भाषा कैसे डिज़ाइन की गई है, मुझे स्पष्ट रूपांतरण का लाभ नहीं दिखता है। यह वैसे भी निहित रूपांतरण से नहीं बचेगा, और यह केवल कोड को पढ़ने और लिखने के लिए और अधिक कठिन बनाता है।

— JacquesB
स्रोत

सच। शायद मुझे इसे इस दृष्टिकोण से इंगित करना चाहिए, कि सबसे समझदारी वाली बात यह सुनिश्चित करना है कि डेटकॉम्पल ऑपरेंड और वैल्यू ऑपरेंड का एक ही डेटाटाइप हो (स्ट्रिंग, डेट, जो भी हो)। मैं विशेष रूप से यह सिफारिश केवल उन सवालों में करता हूं, जहां मुझे पता है कि टेबल कॉलम DATETIME है और उनका उदाहरण उत्तर निहित रूपांतरण के साथ एक स्ट्रिंग ऑपरेंड का उपयोग कर रहा है ..

— कायुस जार्ड

इस उत्तर पर मेरे साथ कुछ सही नहीं बैठता है। आप कुछ दिलचस्प बिंदु बनाते हैं लेकिन मुझे लगता है कि निष्कर्ष आदर्शवादी है। एक डिजाइन के नजरिए से, हां, गैर-आईएसओ तिथि प्रारूप मानव आंख के लिए अस्पष्ट हैं लेकिन अगर स्पष्ट रूपांतरण का उपयोग करते हुए, वाक्य रचना के अनुसार यह पार्सर के लिए अस्पष्ट नहीं है। इसी तरह, डेट्स को शामिल करने वाली कई ईटीएल प्रक्रियाओं में डेटाबेस के डेट फॉर्मेट के स्ट्रिंग के कुछ तुलना (फाइल आयात के रूप में) की आवश्यकता होती है। स्ट्रिंग को खत्म करने की कोशिश करने की तुलना मेरे लिए अवास्तविक है।

— DanK

@DANK: ETL एक अलग मुद्दा है - यदि आप CSV फ़ाइल या कुछ और से डेटा पढ़ रहे हैं, तो जाहिर है आपको डेटा को स्ट्रिंग्स के रूप में संसाधित करना होगा और स्पष्ट रूप से टाइप किए गए मानों में पार्स करना होगा। लेकिन ऐसा नहीं है कि ओपी वर्णन कर रहा है।

— जैक्सबी

यह आसानी से मैं हालांकि वर्णन कर रहा हूँ बिंदु हो सकता है; सीएसवी में संग्रहीत संख्याओं की एक स्ट्रिंग के बारे में कुछ खास नहीं है जो पार्सिंग करते समय प्रारूप को स्पष्ट रूप से घोषित करने की मांग करता है और यह तर्क के लिए प्रासंगिक हो जाता है कि अगर कोई नौसिखिया एसओ में कुछ उत्तर पढ़ता है जहां समर्थक स्पष्ट रूप से कोई प्रयास नहीं करता है। तिथि प्रारूप घोषित करें, नौसिखिया अग्रणी यह मानने के लिए कि उन्हें इसके बारे में चिंता करने की ज़रूरत नहीं है (या कि डीबी इसे हर समय सही तरीके से पार्स करेगा)

— कायुस जार्ड

@ कैयूसजार्ड: मेरा मानना है कि ये बहुत अलग परिदृश्य हैं। सामान्य परिदृश्यों में एसक्यूएल के बारे में बात करते समय, मुझे लगता है कि कॉलम में उपयुक्त प्रकार हैं - यानी पूर्णांक कॉलम पूर्णांक प्रकार हैं, तिथि कॉलम डेटा प्रकार और इसी तरह हैं। यदि आपके पास तालिकाओं में सही प्रकार नहीं हैं (जैसे स्ट्रिंग्स के रूप में दिनांक संग्रहीत करें) तो आप गहरी परेशानी में हैं और प्रश्नों में स्पष्ट रूप से परिवर्तित दिनांक शाब्दिकता आपको नहीं बचाएगी , जो कि मेरी बात है।

— जैक्सबी

3

सबसे पहले और सबसे महत्वपूर्ण, आपके पास एक बिंदु है। तिथियों को तार में नहीं डाला जाना चाहिए। डेटाबेस इंजन जटिल जानवर हैं जहां आप कभी भी 100% निश्चित नहीं हैं कि वास्तव में एक मनमाना क्वेरी दिए गए हुड के तहत क्या होगा। तारीखों में बदलने से चीजें अस्पष्ट हो जाती हैं और प्रदर्शन बढ़ सकता है।

परंतु

यह ज्यादातर लोगों के लिए अतिरिक्त विचार-प्रयास के लायक समस्या नहीं है। यदि किसी क्वेरी में दिनांक शाब्दिक का उपयोग करना आसान था, तो अपनी स्थिति का बचाव करना आसान होगा। लेकिन ऐसा नहीं है। मैं ज्यादातर एसक्यूएल सर्वर का उपयोग करता हूं, इसलिए उस गड़बड़ को याद रखने की कोशिश कर रहा हूं कि एक तारीख को बदलने के लिए अभी कुछ नहीं हो रहा है।

अधिकांश लोगों के लिए, प्रदर्शन लाभ नगण्य है। "क्यों हाँ मिस्टर बॉस-यार, मैंने 10 मिनट का समय इस साधारण बग को ठीक करने में लगाया (मुझे तारीखों को बदलने के लिए गूगल करना पड़ा क्योंकि यह वाक्य रचना है ... विशेष ...)। लेकिन मैंने एक अतिरिक्त 0.00001 सेकंड में बचा लिया। शायद ही कभी निष्पादित क्वेरी। " मैंने जिन स्थानों पर काम किया है, उनमें से अधिकांश के लिए यह उड़ान भरने वाली नहीं है।

लेकिन यह आपके द्वारा कहे गए फॉर्मेट में अस्पष्टता को दूर करता है। फिर से, बहुत सारे अनुप्रयोगों के लिए (कंपनी आंतरिक अनुप्रयोग, स्थानीय सरकारी सामान, आदि) यह वास्तव में एक चिंता का विषय नहीं है। और उन अनुप्रयोगों के लिए जहां यह एक चिंता का विषय है (बड़े, अंतर्राष्ट्रीय या उद्यम अनुप्रयोग), जो या तो एक यूआई / व्यापार परत की चिंता बन जाते हैं या उन कंपनियों के पास पहले से ही अच्छी तरह से वाकिफ डीबीए की एक टीम है जो पहले से ही यह जानते हैं। टीएल / डीआर: यदि अंतर्राष्ट्रीयकरण एक चिंता है, तो कोई पहले से ही इसके बारे में सोच रहा है और पहले से ही जैसा आपने सुझाव दिया है (या अन्यथा इस मुद्दे को कम कर दिया है)।

तो अब क्या?

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

— Becuzz
स्रोत

1

मैं तर्क दे रहा हूं कि इस माध्यम से स्पष्ट होना बुद्धिमानी है जो हमें विभिन्न डेटाटाइप्स की एक स्ट्रिंग्स के रूप में पारित करने के लिए मजबूर करता है।

यह मानते हुए कि " स्ट्रिंग्स " को " स्ट्रिंग्स " में फिर से पास किया जा रहा है ; मैं बिल्कुल सहमत हूँ कि आप ऐसा करने के लिए सही हैं।

"01/04/07" कब है ?
* 4 जनवरी?
* अप्रैल 1?
* 7 अप्रैल [2001]?

इनमें से कोई भी या सभी सही हो सकते हैं, यह इस बात पर निर्भर करता है कि "कंप्यूटर" उनकी व्याख्या करने के लिए कैसे चुनता है।

आप तो है उन में शाब्दिक साथ गतिशील एसक्यूएल, निर्माण करने के लिए तो अपनी तिथि स्वरूपण अच्छी तरह से परिभाषित किया जाना है और, अधिमानतः, मशीन स्वतंत्र (मैं एक विंडोज सर्वर पर एक अजीब है जिसमें एक Windows सेवा के भीतर दिनांक-आधारित प्रसंस्करण धराशायी हो चला गया था क्योंकि कोई ऑपरेटर अलग-अलग दिनांक प्रारूप वरीयताओं के साथ कंसोल पर लॉग ऑन करता है!)। व्यक्तिगत रूप से, मैं विशेष रूप से "yyyy-mm-dd" प्रारूप का उपयोग करता हूं।

तथापि ...

सबसे अच्छा उपाय यह है कि परिधिबद्ध क्वेरीज़ का उपयोग करें जो डेटा प्रकार को SQL में शामिल होने से पहले परिवर्तित करने के लिए मजबूर करते हैं - दिनांक पैरामीटर में "दिनांक" मान प्राप्त करने से टाइप रूपांतरण जल्दी होता है (यह विशुद्ध रूप से एक कोडिंग समस्या है, SQL एक नहीं) ।

— फिल डब्ल्यू।
स्रोत

मैं सहमत हूं, हालांकि एक ही समस्या को पैरामीटर के प्रश्नों के साथ फिर से मजबूर किया जा सकता है, WHERE datecolumn = @dateParameterऔर फिर सामने के अंत कोड में, DB ड्राइवर जो कि @dateParameterप्रकार varchar का है, और इसमें चिपके हुए बता रहा "01/04/07"है। मेरे प्रश्न के लिए मूल प्रेरणा यह है कि मुझे किसी पर शक है, जो मुझे बताएगा कि मैं एक पैरामीटर क्वेरी के लिए ऐसा करने के लिए पागल हूं, फिर, एक ही सांस में, कुछ एक लाइन एसओ उत्तर दें जो दिखता है WHERE datecol = 'some string that looks like a date'(और उम्मीद है कि एक नौसिखिया जानना चाहिए) यह सिर्फ एक संकेत है / मुद्दों से बचने के लिए इसे

— मानकीकृत करें