एक रिलेशनल डेटाबेस में एक कस्टम प्रकार का मॉडल कैसे करें?

Question

मैं डेटाबेस डिजाइन के लिए बिल्कुल नया हूं, लेकिन मैं मूलभूत सिद्धांतों को समझता हूं। मैं एक रिलेशनल डेटाबेस बना रहा हूं और मैं पुन: प्रयोज्य प्रकार या कक्षा बनाने के समान कुछ करना चाहता हूं। उदाहरण के लिए, मान लें कि मेरे पास Customer तालिका और Item तालिका है। ग्राहक और आइटम मानक 1 से कई रिश्ते से संबंधित हैं, इसलिए आइटम में CustomerId नामक कॉलम है।

मैं प्रत्येक ग्राहक और प्रत्येक आइटम के लिए कई "नोट्स" भी पसंद करूंगा। एक सामान्य ओओपी मॉडल में, मैं सिर्फ Note कक्षा बनाउंगा और जब भी मुझे आवश्यकता हो, उसके उदाहरण बनाएं। बेशक, एक संबंधपरक डेटाबेस अलग है। मैं Note तालिका रखने के बारे में सोच रहा था, और मैं ग्राहक और नोट के साथ-साथ आइटम और नोट के बीच 1 से कई रिश्ते चाहता हूं। समस्या यह है कि नोट तालिका में एक दूसरे के लिए एक कॉलम होना चाहिए जो इस "प्रकार" का उपयोग करना चाहता है। (नीचे उदाहरण देखें)

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

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

Answer 1

हां, आपका अंतिम उदाहरण सही है, और जाने का रास्ता होना चाहिए।

आप तालिकाओं को बनाकर संबंधपरक डेटाबेस में "जटिल प्रकार" मॉडल करते हैं। आप तालिका को कक्षा के रूप में देख सकते हैं: वास्तव में ORM समाधान अक्सर कक्षा में सीधे एक तालिका को मानचित्र करते हैं। कस्टम प्रकार का एक उदाहरण इसकी तालिका में एक पंक्ति है, और उदाहरण प्राथमिक कुंजी के मान से संदर्भित किया जा सकता है।

आप "जटिल प्रकार" की प्राथमिक कुंजी के रूप में एक ही डेटा प्रकार का उपयोग कर, और एक foreign key constraint के साथ संबंध को लागू करके अन्य तालिकाओं में क्षेत्रों के लिए अपने कस्टम "जटिल प्रकार" का उपयोग कर सकते हैं:

के एक निर्माण करते हैं "देशों" के लिए जटिल प्रकार:

CREATE TABLE countries (
    iso_code  char(2)  NOT NULL,  
    name   varchar(100) NOT NULL, 
    population bigint  
    PRIMARY KEY (iso_code) 
); 

और के "देश" उदाहरणों में से एक जोड़े को जोड़ने:

INSERT INTO countries VALUES ('IE', 'Republic of Ireland', 4470700); 
INSERT INTO countries VALUES ('US', 'United States of America', 310403000); 

अब हम जा रहे हैं एक "उन" तालिका में हमारे जटिल "देशों" प्रकार का उपयोग करें: ऊपर मॉडल के साथ

CREATE TABLE users (
    id   int   NOT NULL, -- primitive type 
    name  varchar(50) NOT NULL, -- primitive type 
    age   int,      -- primitive type 
    country  char(2),     -- complex type 
    PRIMARY KEY (id), 
    FOREIGN KEY (country) REFERENCES countries (iso_code) 
); 

, हम और गारंटी है कि users तालिका के country क्षेत्र केवल एक वैध देश हो सकता है, और कुछ नहीं बल्कि एक वैध देश ।

इसके अतिरिक्त, junction table का उपयोग करके, जैसा कि आपने सुझाव दिया है, polymorphic relationship से निपटने के लिए भी एक उपयुक्त दृष्टिकोण है। आप इस विषय पर कुछ आगे पढ़ने के लिए निम्न स्टैक ओवरफ़्लो पदों बाहर की जाँच में रुचि हो सकती:

• How can you represent inheritance in a database?
• Possible to do a MySQL foreign key to one of two possible tables?

Answer 2

मुझे लगता है कि आप ग्राहक तालिका और आइटम तालिका में नोट फ़ील्ड को सर्वश्रेष्ठ रूप से जोड़ सकते हैं। इस नोट फ़ील्ड (विदेशी कुंजी) में आप ग्राहक/आइटम से संबंधित नोट की आईडी स्टोर कर सकते हैं। यह सुनिश्चित करने के लिए कि आप किसी ग्राहक या आइटम को एकाधिक नोट्स संलग्न कर सकते हैं, आप नोट्स टेबल जोड़ने और "नोट्स" तालिका में एकल नोट्स संलग्न कर सकते हैं जिसे आप अपने ग्राहक/आइटम तालिका से जोड़ सकते हैं।