क्या किसी को कागजात/किताबें/आदि के बारे में पता है। डेटाबेस के लिए दस्तावेज़ पैटर्न? उदाहरण के लिए, अंगूठे का एक आम नियम यह है कि प्रत्येक तालिका में प्राथमिक कुंजी होनी चाहिए और कुंजी devoid of information content होनी चाहिए। तो मैं सोच रहा था कि क्या किसी ने रिलेशनल डेटाबेस डिजाइन करने के लिए डिज़ाइन पैटर्न के बारे में कोई पुस्तक या प्रकाशित कागजात लिखे हैं?डाटाबेस पैटर्न
@Gaius,
सवाल है कि एक डेटाबेस डिजाइनर वजन करने की जरूरत है कि - डेटाबेस संरचना के संभावित स्थिरता क्या है? लंबे समय तक पर्याप्त क्षितिज को देखते हुए कुछ भी स्थिर नहीं है। या बातचीत करने के लिए, एक लंबे समय तक पर्याप्त क्षितिज दिया, सब कुछ बदलने के अधीन है। एक सरोगेट कुंजी (सिद्धांत में) कभी भी इसका अर्थ नहीं बदलना चाहिए क्योंकि इसका अर्थ कभी शुरू नहीं हुआ था।
मुझे लगता है कि उस विशेष डिजाइन परिदृश्य में विचार करने वाली दूसरी बात यह है कि प्राथमिक कुंजी को कौन देखेगा? यदि प्राथमिक कुंजी कुछ ऐसा है जो अंत उपयोगकर्ताओं को वास्तव में संदर्भित करने की आवश्यकता होगी तो इसे समझने के लिए यह समझ में आता है कि वे कुछ समझ सकते हैं। लेकिन मैं कई मामलों के बारे में नहीं सोच सकता जहां एक अंतिम उपयोगकर्ता को प्राथमिक कुंजी देखने की आवश्यकता होती है; आमतौर पर डीबी इंजन को कुछ परिचालनों को तेज करने की अनुमति देने के लिए प्राथमिक कुंजी मौजूद होती है।
प्रश्न पूछने में मेरा मूल विचार डेटाबेस डिजाइन के लिए डिज़ाइन पैटर्न ढूंढना था जो अपेक्षाकृत अधिक अनुभवी डेटाबेस डिजाइनरों द्वारा संहिताबद्ध किया गया था, उम्मीद है कि कुछ आसानी से बचने योग्य त्रुटियों से बचें। अगर किसी ने कभी डेटाबेस डिज़ाइन एंटी-पैटर्न को कोड किया है तो यह दिलचस्प पढ़ना होगा।
'प्राकृतिक' कुंजी का उपयोग करने का जोखिम यह है कि वे बदल सकते हैं; सरोगेट कुंजी बदल नहीं सकते हैं। सेल्को का लेख कोई मूल्य निर्धारण नहीं करता है जिस पर बेहतर है। यह भी देखें http://stackoverflow.com/questions/159087/composite-primary-keys-versus-unique-object-id-field#159247 –