पहला अधिक सामान्यीकृत है, अगर थोड़ा अधूरा है। आप कुछ दृष्टिकोण अपना सकते हैं, सबसे सरल (और कड़ाई से बोलते हुए, सबसे 'सही') को स्पष्ट FK बाधा के साथ दो तालिकाओं की आवश्यकता होगी।
commentid ---- subjectid ----- idType
--------------------------------------
1 22 post
2 26 photo
3 84 reply
4 36 post
5 22 status
idType
------
post
photo
reply
status
यदि आप चाहें, तो आप कुंजी/सूचकांक लंबाई पर वर्चर के प्रभाव को कम करने के लिए char(1) या इसी तरह का उपयोग कर सकते हैं, या यदि आप एक का उपयोग करने की योजना बना रहे हैं तो ओआरएम के साथ उपयोग की सुविधा के लिए। NULL हमेशा परेशान करते हैं, और यदि आप उन्हें अपने डिजाइन में बदलते हुए देखना शुरू करते हैं, तो बेहतर होगा कि आप उन्हें खत्म करने का एक सुविधाजनक तरीका समझ सकें।
दूसरा तरीका वह है जिसे मैं 100 मिलियन से अधिक पंक्तियों के साथ काम करते समय पसंद करता हूं:
commentid ---- subjectid
------------------------
1 22
2 26
3 84
4 36
5 22
postIds ---- subjectid
----------------------
1 22
4 36
photoIds ---- subjectid
-----------------------
2 26
replyIds ---- subjectid
-----------------------
3 84
statusIds ---- subjectid
------------------------
5 22
निश्चित रूप से (थोड़ा असामान्य) हाइब्रिड दृष्टिकोण भी है, जिसका मैं बड़े डेटासेट के साथ बड़े पैमाने पर उपयोग करता हूं, क्योंकि वे गंदे होते हैं। बस पूर्व-निर्धारित idTypes के लिए विशेषज्ञता तालिकाएँ प्रदान करें, लेकिन एक तदर्थ idType स्तंभ को commentId तालिका पर रखें।
ध्यान दें कि यहां तक कि संकर दृष्टिकोण के लिए केवल 2x अपसामान्यीकृत तालिका के स्थान की आवश्यकता होती है; और idType द्वारा तुच्छ क्वेरी प्रतिबंध प्रदान करता है। हालांकि अखंडता बाधा सीधे आगे नहीं है, टाइप-टेबल के व्युत्पन्न यूनियन पर एफके बाधा होने के नाते। मेरा सामान्य तरीका यह है कि या तो हाइब्रिड टेबल पर ट्रिगर का उपयोग किया जाए, या अपडेट को सही सब-टाइप टेबल में अपडेट करने के लिए समकक्ष-अपडेट करने योग्य-व्यू का उपयोग किया जाए।
सरल दृष्टिकोण और अधिक जटिल उप-प्रकार तालिका दृष्टिकोण दोनों काम करते हैं; फिर भी, अधिकांश उद्देश्यों के लिए KISS लागू होता है, इसलिए मुझे संदेह है कि आपको शायद केवल एक ID_TYPES तालिका, प्रासंगिक FK पेश करनी चाहिए, और इसके साथ किया जाना चाहिए।
