क्या यह सभी डीबी तालिकाओं पर निर्मित तिथि और अंतिम अद्यतन तिथि क्षेत्र सहित मानकीकरण करने के लिए समझ में आता है?


38

मेरे मालिक वर्तमान में हमारी टीम के लिए कुछ विकास मानकों को लागू करने का प्रयास कर रहे हैं, इसलिए हमने कल उन मानकों पर चर्चा करने के लिए एक बैठक की, जो तब तक अच्छी तरह से चल रहे थे, जब तक वह नहीं ले गई:

  • सभी DB तालिकाओं में एक CreatedDate और LastUpdatedDate कॉलम होगा, जो ट्रिगर्स द्वारा अद्यतन किया गया है।

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

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

तो, मेरा सवाल दुगना है:

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

आप यह क्यों कहते हैं कि C # ORM- खुश नहीं है? इसके अलावा, NHibernate में इन दो कॉलमों की मैपिंग के लिए [इन्सर्ट = "गलत" अपडेट = "गलत" उत्पन्न = "हमेशा"] गुणों को जोड़ने से ऐसा नहीं लगता है कि यह मेरे लिए अजीब है, या मैं कुछ याद नहीं कर रहा हूं?
जलयोन

C # + Oracle ORM-happy नहीं है, और हमने पाया कि NHibernate बहुत भारी था (जाहिर है, मैं टूलिंग जांच के उस बिट में शामिल नहीं था)। मैंने मुख्य प्रश्न में संभवतः C # और Oracle को पीछे की ओर रखा है।
एड जेम्स

आपको डेटाबेस मानकों के लिए अधिक वर्णनात्मक होने के लिए अपने प्रश्न के शीर्षक का नाम बदलने पर विचार करना चाहिए।
maple_shaft

ऐसे में किसी चीज से समय कैसे लगेगा? आप इसे 'बाहर के मामलों' के लिए कम से कम दो बार करने जा रहे हैं। एक उपकरण और कुछ पुन: प्रयोज्य कक्षाएं बनाएं और इसके बारे में फिर कभी चिंता न करें।
स्टीवन एवर्स

जवाबों:


27

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

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

अस्वीकरण: हालांकि, एक डेटाबेस ऑडिट ट्रेल हासिल करने के बहुत बेहतर तरीके हैं> https://stackoverflow.com/questions/1051449/ideas-on-database-design-for-capturing-audit-trails


क्षमा करें, उल्लेख करना भूल गया, पीसीआई (आदि) अनुपालन लागू नहीं है, लॉग में पहले से ही प्रक्रिया ऑडिट ट्रेल है (हर चीज पूरी तरह से लॉग इन है)।
एड जेम्स

6
"(हर चीज को अच्छी तरह से लॉग इन किया जाता है)" क्या इसमें क्रिएटेडडेट और लास्टअपडेटेड शामिल है? यदि हां, तो शायद आप अपने सहयोगियों को DRY सिद्धांत की ओर इशारा कर सकते हैं :)
MattDavey

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

3
मुझे नहीं लगता कि इस दृष्टिकोण से एक समृद्ध ऑडिट ट्रेल प्राप्त होगी ... मैं इसे ऑडिट ट्रेल बिल्कुल भी नहीं कहूंगा ।
जोर्डो

@ जोर्डो मैंने कहा कि यह एक सामान्य दृष्टिकोण था, मैंने यह नहीं कहा कि यह एक अच्छा था! इसलिए अस्वीकरण :)
मैटवेवी

17

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

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

लाभ, भले ही डेटाबेस स्तर पर इस तरह की कार्यक्षमता को लागू करने में किसी भी मानवीय लागत से बहुत दूर हो, और निश्चित रूप से परियोजनाओं की सामूहिक मस्तिष्क शक्ति से कम हो, महान तकनीकी दिमाग बैठक को अपहृत करते हैं और इसे एक महाकाव्य छाती डंपिंग मैच में बाहर फैलाते हैं। जब आप उस प्रभाव को टाल देते हैं जो कुछ 1 घंटे की बैठकों में एक परियोजना के जीवनकाल पर होता है तो आपको शायद आश्चर्य नहीं होगा कि वे महंगे हैं। संयुक्त उन सभी लोगों के सामूहिक प्रति घंटा मजदूरी और लाभों की कल्पना करें और जो आपको एक विचार देना चाहिए।


8
एक स्क्रिप्ट बनाएं जो इन स्तंभों को हर तालिका में जोड़ेगी यदि वे पहले से ही ट्रिगर के साथ मौजूद नहीं हैं।
जेएफओ

3
+1 आप कुछ दिनों में आसानी से स्क्रिप्ट उत्पन्न कर सकते हैं। केवल बहुत सारे काम अगर यह मैन्युअल रूप से किया जाता है।
जॉन रेन्नोर

8

... अधिक निश्चित बयान एक आदमी को और अधिक संभावना है कि वह निश्चित रूप से गलत होने की संभावना है ... - टायलर ड्यूरेन

यह कंबल "मानकों" पर लागू होता है, जबकि कुछ तालिकाओं पर यह एक बड़ी जीत हो सकती है, हर मेज पर यह सबसे अधिक बेकार शोर और बनाए रखने या भूल जाने के लिए अधिक कोड होगा।

यहां संतुलन होना चाहिए, यही आपको निर्णय निर्माताओं को आगे बढ़ाना चाहिए।


8

मैं तहे दिल से सहमत हूं। प्रत्येक डेटाबेस में लगभग प्रत्येक तालिका में कम से कम 2 फ़ील्ड होनी चाहिए: निर्माण तिथि और अद्यतन तिथि । कई कारण हैं कि आपको एक बनाने की तारीख और अद्यतन तिथि डालनी चाहिए। स्पष्ट कारणों के लिए कि पूर्व लोगों ने कहा ... जो कि लेखापरीक्षा है।

मैं 25 साल से सिस्टम और डेटाबेस डिजाइन कर रहा हूं और सैकड़ों क्लाइंट्स के लिए काम कर रहा हूं। एक भी ग्राहक नहीं है जिसे इसकी आवश्यकता नहीं थी।

ऐसा करने के 2 मूल तरीके हैं:

1 - पहला अभ्यास डेटाबेस को काम करने देता है और इसे सीधे टेबल डिज़ाइन में डाल देता है। जो नंगे न्यूनतम है, मैं सुझाऊंगा।

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

इन फ़ील्ड्स के होने का एक अन्य लाभ डेटा वेयरहाउस और ODS है जो किसी भी OLTP सिस्टम के लिए बनाया गया है। आप इसके बिना वृद्धिशील डेटा को प्रभावी ढंग से नहीं खींच सकते। अन्यथा आपको हर दिन पूरे डीबी को फिर से लोड करने का जोखिम होता है।

इन 2 तारीखों में डालने के लिए अन्य व्यावसायिक कारणों की एक बड़ी संख्या है, जो मैं यहां नहीं दूंगा। अपना होमवर्क करो और मुझे यकीन है कि सड़क पर 3-6-12-48 महीने तक आप इन 2 सरल क्षेत्रों में डालकर बहुत खुश होंगे।

मैंने लागू किया है और आमतौर पर जहां संभव हो, दोनों समाधानों की सिफारिश करते हैं।


5

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

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

यह डेटा कैसे मदद कर सकता है? खैर पहले यह बताता है कि पुराने डेटा को खोजने के लिए कब देखना है (एक संशोधन में) और यह आपको यह देखने में मदद कर सकता है कि डेटा दर्ज किए जाने के समय आपके प्रोग्राम का कौन सा संस्करण सक्रिय था। इसलिए यदि आप जानते हैं कि आपने संस्करण 2.3 में उस समस्या को ठीक कर लिया है, जो 6 जुलाई 2011 को लाइव हुई थी और फिर उसी समस्या को 7 अगस्त को रिकॉर्ड किए गए रिकॉर्ड के साथ मिला, तो शायद आपका फिक्स अच्छा नहीं था। यदि आपको पुराने डेटा को वापस करने की आवश्यकता है, तो यह आपको बताएगा कि बैकअप के किस संस्करण में आप पुराने डेटा पा सकते हैं यदि आपके पास पूर्ण डेटा नहीं है।

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


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

इकाई परीक्षण ऑडिटिंग से अलग हैं। मैं उल्लेख करता हूं कि यह एक बग को पकड़ सकता है क्योंकि मैंने देखा है कि यह तब भी होता है जब यूनिट परीक्षण होते थे क्योंकि एक अप्रयुक्त किनारे का मामला था। यह भी इंगित कर सकता है कि डेटा बग फिक्स से पहले दर्ज किया गया था और फिर आपको अन्य डेटा ढूंढने की आवश्यकता हो सकती है जिसे फिक्सिंग की भी आवश्यकता है। या बस यह जान लें कि यह 6 जून, 2016 को एक आयात के माध्यम से दर्ज किया गया डेटा था, जो यह देखने में आपकी मदद करता है कि क्या समस्या आपके आयात की थी या आयात फ़ाइल में डेटा के साथ कुछ गड़बड़ है। यह दैनिक आयात फ़ाइलों के वर्षों के माध्यम से देखने की तुलना में पूरी तरह से आसान है।
HLGEM

4

वर्कलोड मूट है क्योंकि इसे स्क्रिप्ट किया जा सकता है और आपके द्वारा बनाए गए हर डेटाबेस पर लागू किया जाएगा। ट्रिगर्स के साथ कॉलम को सभी तालिकाओं में जोड़ें। आपको इसे अपने बिल्ड के साथ चलाने के लिए याद रखना होगा।

जहां तक ​​ग्राहक चाहता है, आप उन्हें अपने ऐप में एकीकृत करने के लिए आपको भुगतान कर सकते हैं, जैसा कि वे फिट देखते हैं। कई लोग रिकॉर्ड पर अतिरिक्त जानकारी देखना पसंद करते हैं जैसे कि इसे अंतिम और कब बनाया / बदल दिया। पता लगाने या झूठ बोलने के लिए सभी को ईमेल भेजने की आवश्यकता नहीं है। जब भी कोई व्यक्ति किसी रिकॉर्ड को देखता है, तो आपको हर बार लॉग इन करने की आवश्यकता नहीं होती है।

इसे डेटाबेस में लाना और वहाँ बस होने की स्थिति में यह उतना मुश्किल नहीं है और आपको अतिरिक्त सुविधाओं के लिए चार्ज करने की अनुमति दे सकता है जो कि खेतों का उपयोग करते हैं या आपको सिस्टम पर कितने क्लाइंट का उपयोग कर रहे हैं इस पर कुछ प्रतिक्रिया देने के लिए।


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

1

यह लागू करने के लिए एक काफी तुच्छ होगा (शायद 1 से 3 दिन कुल), इसलिए मेरी राय में इसके जीवनकाल में आपके आवेदन में जोड़ने के लिए इसका कितना मूल्य है।

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

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

अद्यतन ट्रिगर के साथ डेटा (पिछले बदलाव में बदलाव) को हल किया जा सकता है। फिर से, यह ट्रिगर लगभग सभी तालिकाओं के समान होगा, इसलिए यह ट्रिगर कोड (SQL) कोड किसी भी मौजूदा तालिकाओं के लिए भी उत्पन्न किया जा सकता है।

संभावित रूप से बहुत सीक्वल स्क्रिप्ट कोड होगा (कितनी तालिकाओं पर निर्भर करता है), लेकिन यह एक पैटर्न है जो दोहराने योग्य है, इसलिए आप इसे एक मौजूदा डीबी स्कीमा को देखकर कोड जनरेट कर सकते हैं।


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

यदि यह एक मानक है, तो उम्मीद है कि नए टेबल बनाने वाले डेवलपर मानक का पालन करते हैं। नहीं तो हाँ, बुरा सपना। दृष्टिकोण मौजूदा स्कीमा को गति प्राप्त करने के लिए है, जो कि मानक का पालन करने के लिए डेवलपर पर है।
जॉन रेन्नोर

मुझे लगता है कि उस टिप्पणी में मुख्य शब्द "उम्मीद" है, मुझे यकीन नहीं है कि मुझे ऐसी किसी भी चीज़ पर भरोसा है जो प्रत्येक नए डेवलपर की खुद की इच्छा से होनी चाहिए!
एड जेम्स

2
@ ईडी - सहमत, कोई भरोसा नहीं, कि कोड की समीक्षा क्या है! :)
जॉन रेन्नोर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.