किसी डेटाबेस में, क्या प्रारंभ समय समाप्ति तिथि, या प्रारंभ तिथि और समय की अवधि के रूप में समय अवधि को स्टोर करना बेहतर है?

Question

यह एक पूरी तरह से अनुमानित प्रश्न है: मान लीजिए कि मेरे पास एक डेटाबेस है जहां मुझे किसी उपयोगकर्ता के लिए सदस्यता संग्रहित करने की आवश्यकता है, जो एक विशिष्ट समय (1 महीने, 3 महीने, 6 महीने, 1 वर्ष, आदि) के लिए टिक सकता है।

बेहतर एक मेज Memberships फ़ील्ड (प्रत्येक तिथि एक यूनिक्स टाइमस्टैम्प के रूप में जमा किया जा रहा है) करने के लिए है:

user_id INT, start_date INT, end_date INT

या के रूप में यह स्टोर करने के लिए:

user_id INT , start_date INT, length INT

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

इसके अलावा, यूनिक्स टाइमस्टैम्प समय/दिनांक डेटा संग्रहीत करते समय जाने के तरीके हैं, या DATETIME पसंद करते हैं? मैंने डेटाटाइप (अत्यधिक रूपांतरण) दोनों के साथ समस्याओं में भाग लिया है लेकिन आमतौर पर यूनिक्स टाइमस्टैम्प पर व्यवस्थित होता है। अगर DATETIME की तरह कुछ पसंद किया जाता है, तो यह मेरे पिछले डिज़ाइन प्रश्न का उत्तर कैसे बदलता है?

Answer 1

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

यदि आप सांख्यिकी में अधिक रुचि रखते हैं (औसत सदस्यता अवधि क्या है? कितने लोग एक से अधिक वर्षों से सदस्य हैं?) तो मैंने दूसरा विकल्प चुना होगा।

अत्यधिक रूपांतरण के संबंध में - आप किस भाषा पर प्रोग्रामिंग कर रहे हैं? जावा/रूबी हुडा के तहत जोडा समय का उपयोग करें और यह दिनांक/समय से संबंधित तर्क को बहुत सरल बनाता है।

Answer 2

एक डिजाइन बिंदु से, मुझे इसे प्रारंभ तिथि और सदस्यता की लंबाई के लिए एक बेहतर डिज़ाइन मिल गया है।

समाप्ति तिथि सदस्यता प्रारंभ तिथि + अवधि का व्युत्पन्न है। इस तरह मैं इसके बारे में सोचता हूं।

Answer 3

मैं असहमत हूं। मेरे पास एक प्रारंभ और समाप्ति तिथि होगी - हर बार प्रदर्शन करने पर सहेजें।

Answer 4

दो रणनीतियों कार्यात्मक रूप से समकक्ष हैं, अपना पसंदीदा चुनें।

Answer 5

यदि आप इंडेक्स अंतिम तिथि पर निर्भर करते हैं, तो यह इस बात पर निर्भर करता है कि बदले में आप डेटा से पूछना कैसे चाहते हैं।

यदि आप करते हैं, और यदि आपका डीबीएमएस गणना-आधारित इंडेक्स या अनुक्रमित कॉलम पर इंडेक्स का समर्थन नहीं करता है, तो आपका एकमात्र सहारा भौतिक end_date होना चाहिए ताकि आप इसे सीधे अनुक्रमित कर सकें।

इसके अलावा, मुझे बहुत अंतर दिखाई नहीं देता है।

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

Answer 6

सदस्यता समय के साथ टॉगल कर सकते हैं अगर मैं इस विकल्प का सुझाव है:

user_id INT, 
since_date DATE, 
active_membership BIT 

जहां active_membership राज्य क्या समय के साथ चालू किए जाने पर, और since_date जब यह हुआ का ट्रैक रखने के किया जाता है। इसके अलावा, आप की अनुमति दी सदस्यता लंबाई की परिमित सेट है और जो लंबाई एक निश्चित उपयोगकर्ता उठाया है का ट्रैक रखने की जरूरत है, इस लिए बढ़ाया जा सकता:

user_id INT, 
since_date DATE, 
active_membership BIT, 
length_id INT 

जहां length_id उपलब्ध की एक लुकअप तालिका को उल्लेख करता है और अनुमति दी सदस्यता की लंबाई हालांकि, कृपया ध्यान दें, कि इस मामले में since_date संदिग्ध हो जाता है यदि आपकी सदस्यता की लंबाई बदलना संभव हो। उस मामले में आप इस भी आगे तक बढ़ाना होगा:

user_id INT, 
active_membership_since_date DATE, 
active_membership BIT, 
length_since_date DATE, 
length_id INT 

इस दृष्टिकोण के साथ

यह देखने के लिए कि सामान्य टूट जाती है जब दो तिथियों एसिंक्रोनस रूप से बदलने के लिए आसान है। इसे सामान्य रखने के लिए आपको वास्तव में 6 एनएफ की आवश्यकता है। यदि आपकी आवश्यकताओं को इस दिशा में जा रहा है तो मैं Anchor modeling को देखने का सुझाव दूंगा।