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