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

Question

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

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

संपादित करें: यह सिर्फ पागल जेडीबीसी चालक दिनांक रूपांतरण/कास्टिंग के साथ-साथ समय क्षेत्र और समय स्वरूपण के आसपास उत्पादकता/भ्रम की उत्पादकता/भ्रम की तरह घूमता है। चलो एक बार और सभी के साथ इसे दूर करते हैं।

मुझे अब एहसास है कि मैं जो सुझाव देता हूं उसके खिलाफ एक और कारण यह है कि हम डीबी में जगह को सहेजना चाहते हैं। उस मामले में हम युग के बाद से decaseconds या यहां तक ​​कि बस "सेकंड" हो सकता है। जो भी डिग्री आप अंतरिक्ष को बचाने के लिए चाहते हैं।

Answer 1

कारण मैं सोच सकता हूं कि 1 जनवरी 1 9 70 00:00:00 GMT से पहले की तारीख और समय स्टोर करना है।

हालांकि मुझे आपका दर्द महसूस होता है। ओरेकल तिथि/डेटाटाइम उपचार जेडीबीसी में दर्दनाक है। यह ड्राइवरों के विभिन्न संस्करणों के बीच भी असंगत है!

मुझे लगता है कि मैं अन्य JDBC चालकों में ज्यादा समस्या नहीं पाया है कहना है (अन्य डीबी विक्रेताओं) हालांकि ...

Answer 2

क्या सवाल है? क्या आप पूछ रहे हैं कि यह संभव है? यह उस डेटाबेस पर निर्भर करेगा जिसका आप उपयोग कर रहे हैं, लेकिन मुझे लगता है कि यह सबसे अधिक संभव है। मैंने निश्चित रूप से एंड्रॉइड ऐप्स में एसक्यूएल लाइट के साथ किया है (जो जावा में प्रोग्राम किए गए हैं, अगर आप इससे परिचित नहीं हैं)।

Answer 3

अब समस्या बिल्कुल भी है।

जब तक आपको कुछ क्वेरी की आवश्यकता नहीं होती है जिसमें दिनांक कॉलम पर कुछ गणना होती है, उस स्थिति में, डेटाबेस को दिनांक प्रकार होना चाहिए जो यह समझता है।

आपको शायद इसकी आवश्यकता नहीं है, इसलिए आप अपनी पसंद के किसी भी प्रतिनिधित्व का उपयोग कर सकते हैं।

Answer 4

दिनांक डेटा प्रकार का उपयोग न करने की एकमात्र समस्या यह है कि यदि आपको तिथियों की तुलना करने जैसी चीजों को करने की आवश्यकता है तो आपको अपने ऐप में लंबी मान से रूपांतरण करना पड़ सकता है। आप वैसे भी डेटा स्टोर कर सकते हैं, प्रस्तुति परत वह है जहां यह अधिक समस्याग्रस्त हो सकती है और अतिरिक्त कोड की आवश्यकता होती है। उदाहरण के लिए, कैलेंडर जैसे घटकों को पॉप्युलेट करना।

Answer 5

आप अपने डेटाबेस में दिनांक/समय मानों का प्रतिनिधित्व करने के लिए पूर्णांक या कुछ अन्य उचित प्रकार का उपयोग कर सकते हैं।

• अपने वर्तमान और भविष्य (!!!) अनुप्रयोगों (जावा या अन्यथा) का उपयोग करने वाले डेटाबेस तालिकाओं डेटाबेस पूर्णांकों और तिथि/समय मान के बीच बदलने की आवश्यकता के

  सभी: हालांकि यह समस्या के एक जोड़े को पेश करता है।

• यदि आपके एसक्यूएल प्रश्न, एसक्यूएल संग्रहीत प्रक्रियाओं या एसक्यूएल ट्रिगर्स में प्रासंगिक कॉलम शामिल हैं, तो उन्हें रूपांतरण करने की आवश्यकता हो सकती है। इससे उन्हें सही होने के लिए और अधिक जटिल/कठिन बना दिया जाता है। इसके अलावा, अतिरिक्त जटिलता क्वेरी इंजन को आपकी क्वेरी को निष्पादित करने के धीमे तरीके से वापस आने का कारण बन सकती है ... क्योंकि क्वेरी ऑप्टिमाइज़र यह नहीं समझता कि आप क्या कर रहे हैं।

• तिथियों का प्रतिनिधित्व करने के लिए पूर्णांक का उपयोग करना लोगों के लिए तिथि कॉलम को शामिल करने वाले तालिका के विरुद्ध एसक्यूएल क्वेरी करने के लिए कठिन होगा।

संपादित

आप के रूप में पूर्णांक डेटाबेस विशिष्ट है दिनांकों के लिए कार्य करके स्थान बचाने या नहीं। आईआईआरसी, ओरेकल एक प्राचीन पूर्णांक के रूप में दिनांक/समय मानों को स्टोर करता है। और मुझे उम्मीद है कि कोई भी सभ्य आरडीबीएमएस वही करेगा ... स्टोरेज स्पेस और क्वेरी दक्षता दोनों के लिए।

पूर्णांक के रूप में दिनांक/समय मान संग्रहीत करना टाइमज़ोन समस्या का समाधान नहीं करता है। यह एक मौलिक जटिल समस्या है।

• कुछ मामलों में आप समय पर एक पूर्ण बिंदु का प्रतिनिधित्व करने के लिए दिनांक या दिनांक/समय चाहते हैं।
• अन्य मामलों में, आप भौगोलिक स्थिति/टाइमज़ोन के सापेक्ष समय में एक बिंदु का प्रतिनिधित्व करना चाहते हैं जिसमें कुछ घटना हुई।
• अन्य मामलों में, आप सिस्टम के स्थान, या उपयोगकर्ता के सापेक्ष समय का प्रतिनिधित्व करना चाहते हैं।

फिर ग्रैन्युलरिटी का सवाल है। (स्पष्टता के लिए आईएसओ दिनांक वाक्यविन्यास का उपयोग करना) "1999" का अर्थ "1999-01-01" या "1999-01-01T00: 00: 00" जैसा ही है? और उप-दूसरे परिशुद्धता के बारे में क्या?

बिंदु यह है कि कोई भी सरल SQL दिनांक/समय (या पूर्णांक) प्रतिनिधित्व इस सब से निपट सकता है। बग/मुद्दों/कठिनाइयों का मूल कारण यह है कि प्रोग्रामर अपने कार्यान्वयन में शॉर्टकट लेते हैं और (अधिक महत्वपूर्ण बात) उनकी सोच में बेवकूफ होते हैं।

संपादित 2

अभी भी मुद्दा यह है कि कई समस्याओं का अभी भी तरीका है कि विभिन्न डेटाबेस और उनके संबंधित JDBC चालकों तारीख शाब्दिक और समय क्षेत्रों के बारे में मान्यताओं को संभालने में अंतर के कारण पैदा होती है है। मैं JDBC पर एक विशेषज्ञ नहीं हूँ और SQL मानक (रों) लेकिन जड़ समस्याओं होने लगते हैं: (उदाहरण के लिए) SQL-92 में विनिर्दिष्ट

• डेटाबेस विक्रेताओं पूरी तरह से datetime प्रकार लागू नहीं किया है।
• SQL मानकों डेटाटाइम अक्षरों के लिए एक एकल वाक्यविन्यास निर्दिष्ट नहीं करते हैं, लेकिन डेटाबेस विक्रेता विशिष्ट वाक्यविन्यास की अनुमति देते हैं।
• एसक्यूएल मानकों को टाइमज़ोन को डिफॉल्ट करने की अनुमति देता है, बिना किसी मानक तरीके को निर्दिष्ट करने के लिए (या यहां तक ​​कि पता भी) कि यह क्या डिफ़ॉल्ट है। अधिक विक्रेता-विशिष्ट समाधान।
• जेडीबीसी विनिर्देश किसी एप्लिकेशन को डिफ़ॉल्ट टाइमज़ोन प्राप्त करने या सेट करने का तरीका प्रदान नहीं करता है, या दिनांक-समय शाब्दिक वाक्यविन्यास का चयन नहीं करता है।

यह सब जावा डेवलपर के लिए पोर्टेबिलिटी और कॉन्फ़िगरेशन समस्याओं की गड़बड़ी तक जोड़ता है।हालांकि, मुझे नहीं लगता कि यह पोर्टेबिलिटी और कॉन्फ़िगरेशन समस्याओं से काफी खराब है जो हमें जावा/आरडीबीएमएस अनुप्रयोगों के अन्य पहलुओं के साथ मिलता है। और पूरी तरह से डेटाटाइम प्रकारों को मिटाने से, आप अन्य समस्याओं का एक गुच्छा खरीद रहे होंगे; ऊपर देखो।

Answer 6

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

प्रदर्शन के लिए कनवर्ट करने के लिए लगभग हर प्रमुख प्रोग्रामिंग/वेब भाषा में यह छोटा है। असल में पूर्णांक यूनिक्स युग की तारीख को सीधे एक वेब पेज पर धक्का दिया जा सकता है और जावास्क्रिप्ट को स्थानीय समय में मध्यवर्ती रूपांतरण से परहेज करने की अनुमति देता है।

एकमात्र जगह यह अच्छी तरह से काम नहीं करती है कैलेंडर अंकगणितीय में: 1 महीने से 31 जनवरी तक जोड़ें।

Answer 7

बस यूटीसी लम्बी (बिग इंटीजर) स्टोर करें, और डीबी कॉलम नाम को इंगित करें कि यह millis_since_epoch (हो सकता है कि टिप्पणी का भी उपयोग कर सके लेकिन मुझे सभी डीबी की समर्थन टिप्पणियां निश्चित नहीं हैं)। इस तरह आप बिना किसी चिंता के डेटा को किसी भी डीबी में स्थानांतरित कर सकते हैं, डेटा को सुरक्षित रूप से उस ऐप के बाहर व्याख्या किया जा सकता है जिसने इसे बनाया है (यही कारण है कि डीबी कॉलम नाम इतना महत्वपूर्ण है), और आप प्रस्तुति/क्षेत्र को संभाल सकते हैं हालांकि आपको यूआई के माध्यम से आवश्यकता है ।