मुझे PostgreSQL के INHERITS . के साथ सबसे बड़ी समस्या है कार्यान्वयन यह है कि आप मूल तालिका में विदेशी कुंजी संदर्भ सेट नहीं कर सकते हैं। बहुत सारे बहुत हैं उन मामलों में जहां आपको ऐसा करने की आवश्यकता है। मेरे उत्तर के अंत में उदाहरण देखें।
रेल के बाहर टेबल, दृश्य या ट्रिगर बनाने का निर्णय महत्वपूर्ण है। एक बार जब आप ऐसा करने का निर्णय लेते हैं, तो मुझे लगता है कि आप सबसे अच्छी संरचना का भी उपयोग कर सकते हैं जो आपको मिल सकती है।
मैंने लंबे समय से बेस पैरेंट टेबल का इस्तेमाल किया है, विदेशी कुंजियों का उपयोग करके अलग-अलग उपप्रकारों को लागू किया है। यह संरचना गारंटी देती है कि केवल एक संघ मौजूद हो सकता है, और यह कि संघ मूल तालिका में सही उपप्रकार का समाधान करता है। (बिल कार्विन के SQL एंटीपैटर्न पर स्लाइड शो में , यह दृष्टिकोण स्लाइड 46 पर शुरू होता है।) इसके लिए साधारण मामलों में ट्रिगर्स की आवश्यकता नहीं होती है, लेकिन मैं आमतौर पर प्रति उपप्रकार एक अद्यतन करने योग्य दृश्य प्रदान करता हूं, और दृश्यों का उपयोग करने के लिए क्लाइंट कोड की आवश्यकता होती है। PostgreSQL में, अद्यतन करने योग्य विचारों को ट्रिगर या नियम लिखने की आवश्यकता होती है। (9.1 से पहले के संस्करणों में नियमों की आवश्यकता होती है।)
सबसे सामान्य स्थिति में, असंबद्ध उपप्रकारों में समान संख्या या प्रकार की विशेषताएँ नहीं होती हैं। इसलिए मुझे अद्यतन करने योग्य दृश्य पसंद हैं।
टेबल इनहेरिटेंस पोर्टेबल नहीं है, लेकिन इस तरह की संरचना है। आप इसे MySQL में भी लागू कर सकते हैं। MySQL में, आपको CHECK बाधाओं को विदेशी कुंजी संदर्भों के साथ एक-पंक्ति तालिकाओं में बदलना होगा। (MySQL पार्स करता है और CHECK बाधाओं को अनदेखा करता है।)
मुझे नहीं लगता कि आपको डेटा डुप्लिकेशन के बारे में चिंता करने की ज़रूरत है। सबसे पहले, मुझे पूरा यकीन है कि पैरेंट टेबल और इनहेरिटिंग टेबल के बीच डेटा को डुप्लिकेट नहीं किया गया है। बस यही नज़र आता है। दूसरे स्थान पर, दोहराव या व्युत्पन्न डेटा जिसकी अखंडता पूरी तरह से डीबीएमएस द्वारा नियंत्रित होती है, निगलने के लिए विशेष रूप से कड़वी गोली नहीं है। (लेकिन अनियंत्रित दोहराव है।)
कुछ विचार करें कि क्या डिलीट को कैस्केड करना चाहिए।
- एक प्रकाशन उदाहरण SQL कोड के साथ।
- एक "पार्टियां" उदाहरण SQL कोड के साथ।
