2011-12-30 20 views
5

किसी उपयोगकर्ता के धर्म को "उपयोगकर्ता तालिका" में संग्रहीत करते समय, ताकि यदि आप एक कॉलम को देखते हैं तो आपको कई बार "ईसाई" दिखाई देगा, "मुस्लिम" कई बार, सामान्य रूप में विफलता माना जाता है? कौन सा फॉर्म?क्या यह सामान्य रूप विफलता माना जाता है?

तरह से मैं इसे देख:

  • 1nF: कोई दोहरा स्तंभ हैं।

  • 2 एनएफ: कोई समेकित प्राथमिक कुंजी नहीं है, इसलिए यह लागू नहीं होता है।

  • 3 एनएफ: गैरकी विशेषता पर कोई निर्भरता नहीं है।

उपयोगकर्ता धर्म भंडारण इस तरह से किसी भी सामान्य रूप असफल प्रतीत नहीं होता है, लेकिन यह लगता बहुत अक्षम। टिप्पणियाँ?

उत्तर

6

आपका डिज़ाइन सभी सामान्य रूपों का समर्थन करता है। यह ठीक है कि आपकी विशेषता का एक स्ट्रिंग मान है। सामान्यीकरण के लिए डेटा प्रकार का आकार अप्रासंगिक है।

सामान्यीकरण का लक्ष्य भौतिक भंडारण दक्षता नहीं है - लक्ष्य विसंगतियों को रोकने के लिए है। और लॉजिकल दक्षता का समर्थन करने के लिए, यानी केवल एक बार एक दिए गए तथ्य को स्टोर करें। इस मामले में, तथ्य यह है कि किसी दिए गए पंक्ति पर उपयोगकर्ता ईसाई है।

+0

मेरी इच्छा है कि मैं इसे इस तरह रखना चाहूंगा। – Taymon

+0

इस मॉडल में डेटा संशोधन विसंगतियों को वास्तव में कुछ बाधा (जांच या विदेशी कुंजी) के बिना कैसे रोक दिया जाता है? (किसी ओआरएम या ऐसे) के माध्यम से किसी भी ग्राहक कोड प्रवर्तन को अनदेखा करना – gbn

+0

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

4

उस तरीके से कॉलम को संग्रहीत करने का सिद्धांत नुकसान भंडारण स्थान में है क्योंकि पंक्तियों की संख्या स्केल हो जाती है।

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

भंडारण स्थान के अलावा उन्हें अन्य तालिका में रखने के अलावा अन्य फायदे हैं। उन्हें संशोधित करना एक तस्वीर है। Christianity को Christian बदलने के लिए, आप संभावित महंगा कर के बजाय (यदि आप पंक्तियों के बहुत सारे है और धर्म अनुक्रमित नहीं है) धर्मों तालिका के एक ही परिवर्तन कर सकते हैं,

UPDATE users SET religion='Christianity' WHERE religion='Christian' 

... आप कर सकते हैं बहुत आसान और सस्ता

UPDATE religions SET name='Christianity' WHERE id=123 

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

+1

महान अंतर्दृष्टि, लेकिन सवाल खड़ा है। आप कहते हैं "denormalized तरीके"। कौन सा सामान्य रूप विफलता यहां लागू होती है? 1 एनएफ, 2 एनएफ या 3 एनएफ? – user

+1

@ user1122200 मुझे लगता है कि यह सख्ती से पहले 3 एनएफ का उल्लंघन नहीं है, लेकिन अक्षमता से स्केल करेगा। –

+0

यही वह है जो मैं पूछ रहा हूं। यह एक सामान्य रूप विफलता प्रतीत नहीं होता है। मैं सामान्य रूप के बारे में, स्केलिंग के बारे में चिंतित नहीं हूं। ऐसा लगता है कि इसे इस तरह स्टोर करने के लिए बदसूरत और अक्षम है, लेकिन ऐसा लगता है कि यह सही ढंग से सामान्यीकृत होगा। – user

1

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

मान लें कि धर्म अपनी मेज में संग्रहीत हैं। यदि आप अच्छी तरह से स्थापित प्रथाओं का पालन कर रहे हैं, तो इस तालिका में प्राथमिक कुंजी होगी जो एक पूर्णांक है, और तालिका में प्रविष्टियों के सभी संदर्भ अन्य तालिकाओं (जैसे उपयोगकर्ता तालिका) में विदेशी कुंजी होंगे। धर्म संग्रह करने की स्ट्रिंग विधि किसी भी सामान्य रूप का उल्लंघन नहीं करती है (क्योंकि धर्म का नाम धर्म तालिका के लिए उम्मीदवार कुंजी है), लेकिन यह तारों के रूप में तारों का उपयोग न करने की प्रथा का उल्लंघन करता है।

(यह संबंध बीजगणित के सिद्धांत और अभ्यास के बीच एक दिलचस्प अंतर है। सिद्धांत रूप में, एक स्ट्रिंग एक पूर्णांक से अलग नहीं है; वे दोनों परमाणु गणितीय मूल्य हैं। अभ्यास में, तारों में बहुत अधिक उपर है प्रोग्रामर उन्हें कुंजी के रूप में उपयोग नहीं करते हैं।)

बेशक, अपने स्वयं के फायदे और नुकसान के साथ प्रत्येक संभावित मानों की सूची के भंडारण के इस तरह के कुछ RDBMSes के लिए Enum के रूप में अन्य तरीकों() कर रहे हैं।

+0

"लेकिन यह तारों के रूप में तारों का उपयोग न करने की प्रथा का उल्लंघन करता है" स्ट्रिंग कुंजी नहीं होगी। अगर इन्हें एक अलग टेबल में ले जाया गया, तो मैं एक धर्मनिरपेक्ष बनाउंगा जो संख्यात्मक – user

+0

है मुख्य मुख्य बिंदु यहां दक्षता है। एक अतिरिक्त तालिका जोड़ने का मतलब अतिरिक्त जुड़ाव होगा, जो ठीक है, लेकिन जब यह रणनीति एकाधिक विशेषताओं के लिए उपयोग नहीं की जाती है। इससे उपयोगकर्ता के बारे में जानकारी खींचने के लिए कई जुड़ सकते हैं। बहुत अधिक जोड़। और यदि यह विधि सामान्य रूप का उल्लंघन नहीं करती है, तो मुझे अतिरिक्त तालिका जोड़ने का कोई कारण नहीं दिखता है। – user

0

आपके सामान्य रूप थोड़ा सा भयानक हैं। दूसरा सामान्य रूप यह है कि शेष पंक्ति "पूरी कुंजी" पर निर्भर करती है। तीसरा सामान्य रूप यह है कि शेष पंक्ति "कुंजी के अलावा कुछ भी नहीं" पर निर्भर करती है। (तो मुझे कोडड मदद करें)।

नहीं, वर्णित आपकी स्थिति पहले तीन सामान्य रूपों में से किसी का उल्लंघन नहीं करती है। (यह अन्य कारकों के आधार पर छठे का उल्लंघन कर सकता है)।

+0

बताए गए सामान्य रूप ठीक हैं। आपका संस्करण एक ही चीज़ को पुन: स्थापित करता है। "पूरी कुंजी" एक समेकित प्राथमिक कुंजी के दोनों भागों को संदर्भित करती है। "कुछ भी नहीं बल्कि कुंजी" किसी अन्य गैरकी विशेषता के आधार पर एक गैरकी विशेषता को संदर्भित करता है। – user

+0

आह, क्षमा करें, मैंने सोचा था कि आपका मतलब है कि दूसरा सामान्य रूप समग्र प्राथमिक कुंजी से वंचित है। मेरी गलती। मैंने एक वाक्यांश के रूप में 'concatenated प्राथमिक कुंजी' नहीं सुना है, तो बस इसके अर्थ पर अनुमान लगाया। –

0

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

इस तकनीक के साथ मुख्य समर्थक डेटा खींचने के लिए तेज़ है (तालिका में शामिल नहीं हो रहा है) और यह मनुष्य को पढ़ने के लिए भी तेज़ है।

+0

मैं यहां सुझाए गए एक mySQL enum का उपयोग करने के बारे में सोच रहा था, या एसक्यूएल में एक जांच बाधा। इससे डेटा त्रुटियों (पूंजीकरण, वर्तनी, आदि) को खत्म कर दिया जाएगा। आपको कैसे लगता है कि यह विधि भंडारण को बर्बाद कर देती है और धीमी है? – user

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