2011-04-20 13 views
6

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

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

मुझे लगता है कि डेटा अपडेट के सेट को 'डेटा सबमिशन' में समूहीकृत किया जाएगा और डेटा को फिर से सत्यापित और सही/अस्वीकार/अनुमोदित किया जाएगा जब कोई गुणवत्ता सबमिशन को नियंत्रित करे।

मैं संबंध के बारे में दो स्थितियों सोचा है डेटा भंडारण के लिए:

1) लाइव डेटा के रूप में एक ही तालिका में लंबित स्थिति डेटा रखते हुए, लेकिन एक झंडा अपनी स्थिति को इंगित करने जोड़ने। मैं 'अपूर्ण' स्थिति डेटा का समर्थन करने के लिए बाधाओं को दूर करने या आवश्यक फ़ील्ड को निरस्त करने के साथ यहां मुद्दों को देख सकता था। फिर मौजूदा डेटा को अपडेट करने के तरीके के साथ समस्या है, आपको अपडेट के लिए एक नई पंक्ति जोड़नी होगी और उसे मौजूदा 'लाइव' पंक्ति से लिंक करना होगा। यह मेरे लिए थोड़ा गन्दा लगता है।

2) नई टेबल जोड़ें जो लाइव टेबल को मिरर करें और डेटा को तब तक स्टोर करें जब तक इसे स्वीकृत नहीं किया जाता है। यह मुझे मौजूदा लाइव टेबल पर पूर्ण नियंत्रण रखने की अनुमति देगा, जबकि 'लंबित' टेबल का दुरुपयोग किया जा सकता है, जिसे उपयोगकर्ता को लगता है कि वह वहां रखना चाहता है। इसका नकारात्मक पक्ष यह है कि मैं डीबी में कई अतिरिक्त टेबल/एसपी के साथ समाप्त हो जाऊंगा। एक और मुद्दा जो मैं सोच रहा था वह था कि उपयोगकर्ता दो रिकॉर्ड के बीच कैसे लिंक कर सकता है, जिससे रिकॉर्ड किया गया रिकॉर्ड लाइव टेबल या लंबित तालिका में एक रिकॉर्ड हो सकता है, लेकिन मुझे लगता है कि इस स्थिति में आप हमेशा एक प्रतिलिपि ले सकते हैं जुड़े रिकॉर्ड और इसे एक अद्यतन के रूप में इलाज?

न तो समाधान सही लगते हैं, लेकिन दूसरा मुझे बेहतर विकल्प जैसा लगता है - क्या कोई तीसरा समाधान है?

उत्तर

2

आपका विकल्प 2 सबसे अच्छा विचार जैसा लगता है। यदि आप रेफरेंसियल अखंडता और डीबीएमएस के साथ प्राप्त होने वाली सभी अच्छी चीजों का उपयोग करना चाहते हैं तो आपके पास एक ही तालिका में लंबित डेटा नहीं हो सकता है।लेकिन वहां अनियंत्रित डेटा होने की कोई आवश्यकता नहीं है- लंबित डेटा अभी भी संरचित है और संभवतः आप डीबी चाहते हैं कि इस डेटा पर भी नियम लागू करने में डीबी खेलें। यहां तक ​​कि यदि आपने नहीं किया है, तो लंबित डेटा मानक तालिका संरचना में अच्छी तरह फिट बैठता है।

टेबल का एक अलग सेट सही जवाब लगता है। आप लंबित तालिका में पंक्ति की प्राथमिक कुंजी को बदल सकते हैं ताकि आप जान सकें कि किस आइटम को संपादित किया जा रहा है, या किस आइटम से लिंक किया जा रहा है।

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

मुझे यकीन नहीं है कि यह फिट बैठता है लेकिन यह SQL सर्वर की मास्टर डेटा सेवाओं जैसे 'मास्टर डेटा प्रबंधन' टूल को देखने लायक हो सकता है।

0

'Unit of work' 'डेटा सबमिशन' के लिए एक अच्छा नाम है।

आप इसे एक अलग स्थान पर क्रमबद्ध कर सकते हैं, जैसे (गैर-रिलेशनल) दस्तावेज़-उन्मुख डेटाबेस, और केवल डीबी को अनुमोदन पर रिलेशनल करने के लिए सहेजें।

इस बात पर निर्भर करता है कि कितने लाइव डेटा बाधाओं को अभी भी अस्वीकृत डेटा पर लागू करने की आवश्यकता है।

0

मुझे लगता है कि दूसरा विकल्प बेहतर है। इसे प्रबंधित करने के लिए, आप व्यू का उपयोग कर सकते हैं जिसमें दोनों टेबल होंगे और आप इस संरचना के साथ दृश्य के माध्यम से काम कर सकते हैं।


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

0

पहला scenerio अच्छा प्रतीत होता है। तालिका में स्थिति कॉलम जोड़ें। निरर्थक बाधा को हटाने की कोई आवश्यकता नहीं है, ध्वज के आधार पर आवश्यक फ़ील्ड को जांचने के लिए केवल एक फ़ंक्शन जोड़ें जैसे ध्वज 1 (अपूर्ण) नल की अनुमति है अन्यथा अनुमति नहीं है। दूसरे संदेह के संबंध में क्या आप डेटा जोड़ना चाहते हैं या पूरे डेटा को अपडेट करना चाहते हैं।

संबंधित मुद्दे