2009-07-14 15 views
13

मैं टेबल बनाने और डेटा जोड़ने के लिए कुछ संग्रहीत प्रक्रियाओं को लिख रहा हूं। खेतों में से एक एक स्तंभ है जो प्रतिशत इंगित करता है। मूल्य 0-100 होना चाहिए। मैंने सोचना शुरू कर दिया, "इसके लिए डेटा सत्यापन कहाँ किया जाना चाहिए? सामान्य रूप से डेटा सत्यापन कहाँ किया जाना चाहिए? क्या यह स्थिति की स्थिति में मामला है?"डेटाबेस स्तर पर डेटा सत्यापन किया जाना चाहिए?

यह मेरे लिए होता है कि हालांकि आज मैंने फैसला किया है कि 0-100 प्रतिशत के लिए वैध मान है, कल, मैं तय कर सकता हूं कि कोई भी सकारात्मक मूल्य मान्य है। तो यह एक व्यापार नियम हो सकता है, है ना? क्या डेटाबेस स्तर पर व्यवसाय नियम लागू किया जाना चाहिए?

बस मार्गदर्शन की तलाश में, हमारे पास अब एक डीबीए नहीं है।

+0

रिटाग किया गया। यह प्रश्न डेटाबेस प्लेटफ़ॉर्म और एप्लिकेशन प्लेटफ़ॉर्म दोनों से स्वतंत्र है। दूसरी तरफ कोई आसान सही जवाब नहीं है। – Richard

+0

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

उत्तर

12

आम तौर पर, मैं कई स्थानों में सत्यापन करना होगा:

  1. क्लाइंट साइड कोड में
  2. सर्वर साइड सत्यापन aspx पृष्ठ पर प्रमाणकों का उपयोग कर के पीछे

मैं एक के रूप में डेटाबेस सत्यापन का उपयोग अंतिम उपाय क्योंकि डेटाबेस यात्रा आमतौर पर ऊपर चर्चा की गई दो मान्यताओं की तुलना में अधिक महंगी होती है।

मैं निश्चित रूप से यह नहीं कह रहा हूं कि "डेटाबेस में सत्यापन न रखें", लेकिन मैं कहूंगा, यह एकमात्र ऐसा स्थान न होने दें जो आपने मान्यताओं को रखा है।

यदि आपका डेटा एकाधिक अनुप्रयोगों द्वारा खपत किया जाता है, तो सबसे उपयुक्त स्थान मध्यम स्तर होगा जो एकाधिक ऐप्स द्वारा उपभोग किया जाना चाहिए (होना चाहिए)।

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

+0

आम तौर पर बोलते हुए, मैं आपसे सहमत हूं। मैं उपयोगकर्ता इंटरफेस के साथ - उच्चतम स्तर पर सत्यापन को संभालने के लिए प्रवृत्त करता हूं। कहने के संदर्भ में, WinForms ऐप, मेरे पास UIP नियंत्रण त्रुटिप्रदाता के साथ ईवेंट प्रदान करता है। मुझे नहीं लगता कि यह हर स्तर पर सत्यापन करने के लिए दर्द होता है, और प्रत्येक स्तर पर प्रलेखन के लिए कहता है कि ऊपर क्या सत्यापन किया गया था और किस मूल्य की अपेक्षा की गई थी। –

+0

मैं उससे सहमत हूं। मुझे इसके लिए मेरे उत्तर का हिस्सा बदलने दो। –

+0

एकमात्र समस्या यह है कि प्रत्येक स्तर पर सत्यापन के साथ, परिवर्तन करने में दर्द होता है। यदि सत्यापन निम्नतम स्तर पर है, तो आपको केवल एक बदलाव करने की आवश्यकता है। नकारात्मकता शायद यह है कि आपको डीबी को अपडेट करने की आवश्यकता है, जो एक अच्छी बात हो सकती है या नहीं भी हो सकती है। – MedicineMan

0

आप डेटाबेस को उचित रूप से प्रतिबंधित कर सकते हैं ताकि डेटा हमेशा समझ में आता है। एक डेटाबेस एक ही डेटा का उपयोग कर कई अनुप्रयोगों का समर्थन करेगा ताकि कुछ प्रतिबंध समझ सकें।

मुझे लगता है कि ऐसा करने में केवल वास्तविक लागत समय होगी। मुझे लगता है कि जब तक आप कुछ पागल नहीं कर रहे हैं तब तक ऐसे प्रतिबंध एक बड़े सौदे नहीं हैं। और, यदि आवश्यक हो तो आप नियमों को बाद में बदल सकते हैं (हालांकि कुछ बदलाव दूसरों की तुलना में स्पष्ट रूप से कठिन हैं)

2

यह इस बात पर निर्भर करेगा कि आप डेटाबेस, आईएमओ के साथ कैसे बातचीत कर रहे हैं। उदाहरण के लिए, यदि डेटाबेस के लिए एकमात्र तरीका आपके आवेदन के माध्यम से है, तो बस वहां सत्यापन करें।

यदि आप अन्य अनुप्रयोगों को डेटाबेस अपडेट करने की अनुमति देने जा रहे हैं, तो आप डेटाबेस में सत्यापन रखना चाहते हैं, ताकि कोई फर्क नहीं पड़ता कि डेटा कैसे प्राप्त होता है, यह निम्नतम स्तर पर मान्य हो जाता है।

लेकिन, उपयोगकर्ता को यह जानने के लिए सबसे तेज़ अवसर देने के लिए सत्यापन करना चाहिए कि समस्या है।

आपने SQL सर्वर का कौन सा संस्करण उल्लेख नहीं किया है, लेकिन आप उपयोगकर्ता परिभाषित डेटाटाइप देख सकते हैं और देख सकते हैं कि इससे आपकी मदद मिलेगी, क्योंकि आप केवल सत्यापन को केंद्रीकृत कर सकते हैं।

+0

इस मामले में डेटाबेस में डेटा डालने वाला एक एप्लिकेशन है। रिपोर्ट के लिए शायद एक और आवेदन डेटा खींच रहा है। – MedicineMan

1

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

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

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

3

सामान्यतः, मुझे लगता है कि डेटा के सत्यापन के करीब, बेहतर होगा।

इस तरह, यदि आपको कभी भी शीर्ष स्तर के एप्लिकेशन को फिर से लिखना होगा या आपके पास डेटा एक्सेस करने वाला दूसरा एप्लिकेशन है, तो आपके पास एक ही डेटा पर चलने वाले (संभावित रूप से अलग) कोड की दो प्रतियां नहीं हैं।

+1

आप उन लोगों से क्या कहते हैं जिन्होंने कहा है कि सत्यापन उपयोगकर्ता के करीब होना चाहिए, इसलिए आप डीबी/सर्वर चक्र का उपयोग नहीं करते हैं? – MedicineMan

+2

ठीक है अगर केवल एक प्रविष्टि बिंदु है, तो यह ठीक है, लेकिन यदि एकाधिक प्रविष्टि बिंदु हैं, तो प्रत्येक बिंदु को अपनी सत्यापन प्रणाली की आवश्यकता होगी। यदि आपके पास वेबसाइट, टर्मिनल और एसएसएच एक्सेस है, तो यह 3 अलग-अलग कार्यान्वयन के साथ सत्यापन के 3 स्तर है; एक में एक दोष आपको कमजोर छोड़ सकता है। अंतिम गंतव्य के करीब सत्यापन को स्थानांतरित करके, सत्यापन को बाईपास करके खराब डेटा में "चुपके" का एक कम मौका है। – samoz

1

एक के लिए एक मामला बना सकते हैं:

  • डेटाबेस में (उदा अतः इस हर प्रश्न/उत्तर कम से कम एक संशोधन है हो सकता है) काफी समग्र डाटा अखंडता को सुनिश्चित करने को लागू।

  • प्रस्तुति और व्यापार तर्क परत के बीच की सीमा में डाटा सुनिश्चित

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

एकमात्र चीज जिसे मैं टालने का प्रयास करता हूं, डेटाबेस में ट्रिगर्स का उपयोग कर रहा है, जबकि वे विरासत की समस्याओं को हल कर सकते हैं (यदि आप ग्राहकों को नहीं बदल सकते हैं ...) वे एक दूरी विरोधी पैटर्न पर कार्रवाई का मामला हैं।

+0

क्या आप डेटाबेस और एप्लिकेशन रिलेशनशिप के बारे में समग्र दर्शन के बारे में अपनी टिप्पणी पर विस्तार कर सकते हैं? – MedicineMan

1

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

3

यदि आपके पास अच्छी डेटा पहुंच स्तर है, तो इससे कोई फ़र्क नहीं पड़ता कि आप कौन सी दृष्टिकोण लेते हैं।

उस ने कहा, एक डेटाबेस बाधा एक अनुप्रयोग-परत बाधा से बाईपास (जानबूझकर या आकस्मिक रूप से) करना बहुत कठिन है।

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

+0

तो क्या आप डेटा एक्सेस स्तर में सत्यापन डालते हैं? – MedicineMan

+0

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

+0

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

0

पहला आदर्श: "गेटकीपर" है ताकि आपके डेटा की स्थिरता प्रत्येक डेवलपर पर समान नियम लागू करने पर निर्भर न हो। सीमा सत्यापन के रूप में सरल सत्यापन डीबी में उचित रूप से कार्यान्वित किया जा सकता है। यदि यह कम से कम बदलता है तो आपके पास कहीं जगह है।

परेशानी "व्यवसाय नियम" अधिक जटिल हो जाती है। यह अनुप्रयोग स्तर पर ऑफलोड प्रसंस्करण के लिए उपयोगी हो सकता है जहां जटिल तर्क प्रबंधन के लिए ओओ भाषा बेहतर हो सकती है।

चाल तब ऐप टियर को ढांचा बनाना है ताकि द्वारपाल स्पष्ट और अपूर्ण हो।

एक छोटे से संगठन (कोई डीबीए ergo, छोटा?) में मैं व्यवसाय नियमों को रखना होगा जहां आपके पास मजबूत विकास विशेषज्ञता है।

यह उच्च स्तर में प्रारंभिक सत्यापन कर अलग नहीं करता, उदाहरण के लिए आप उपयोगकर्ता यह सही पाने में मदद करना यूआई में सभी तरह से मान्य सकता है, लेकिन तुम नहीं कि प्रारंभिक मान्यता पर निर्भर - अभी भी आप द्वारपाल है

+0

मैंने डेटा सत्यापन उद्देश्यों के लिए गेटकीपर के बारे में नहीं सुना है। क्या यह एक डिज़ाइन पैटर्न है जिसे आपने डेटा सत्यापन के लिए उपयोग किया है? – MedicineMan

+0

डिजाइन करते समय मैं जिम्मेदारियों के प्राथमिक मालिकों की तलाश करता हूं। प्रमाणीकरण एक ऐसी जिम्मेदारी है। इस संदर्भ में "द्वारपाल" शब्द वैधता श्वसनशीलता के मालिक के लिए मेरा स्वयं का कार्यकाल है, मुझे उम्मीद है कि यह एक प्राधिकरण के विचार में हो जाएगा। – djna

0

यदि आप प्रतिशत हमेशा 'भाग से विभाजित होते हैं' (और आप भाग और पूरे मूल्यों को कहीं और नहीं बचाते हैं), तो [0-100] के खिलाफ अपना मान जांचना डीबी स्तर पर उपयुक्त है। अतिरिक्त बाधाओं को अन्य स्तरों पर लागू किया जाना चाहिए।

यदि आपका प्रतिशत किसी प्रकार का विकास है, तो उसके पास किसी भी प्रकार का मूल्य हो सकता है और डीबी स्तर पर जांच नहीं की जानी चाहिए।

यह स्थिति की स्थिति के मामले में है। आम तौर पर आपको डीबी स्तर पर केवल बाधाओं की जांच करनी चाहिए, जो कभी भी प्राकृतिक सीमाओं को बदल नहीं सकती है (जैसे पहले उदाहरण)।

0

रिचर्ड सही है: प्रश्न यहां से पूछे जाने वाले तरीके से व्यक्तिपरक है।

एक और लेना है: इस पर विचार के स्कूल क्या हैं? क्या वे क्षेत्र या प्रौद्योगिकी से भिन्न होते हैं?

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

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

हालांकि: सबसे पुरानी चीजें होती हैं और कभी-कभी डीबी को ऐसे मान मिलते हैं जो व्यवसाय-परत कोड को "असंभव" पढ़ते हैं। तो यदि आप वित्तीय डेटा का प्रबंधन कर रहे हैं, तो मैं हर स्तर पर हर एक बाधा को संभव कहूंगा। विभिन्न क्षेत्रों के लोग क्या करते हैं?

+0

क्या यह वास्तव में व्यक्तिपरक है? शायद मुझे इसके बजाय सबसे अच्छा अभ्यास करने के लिए कहा जाना चाहिए था। – MedicineMan

+0

मुझे नहीं पता कि यह व्यक्तिपरक है ... मुझे लगता है कि यह शायद ठीक है। –

1

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

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