SQL सर्वर

Question

में पारस्परिक रूप से अनन्य रिश्ते का मॉडल कैसे करें मुझे किसी मौजूदा एप्लिकेशन में कार्यक्षमता जोड़नी है और मैंने डेटा स्थिति में भाग लिया है कि मुझे यकीन नहीं है कि मॉडल कैसे करें। मुझे नई टेबल और कोड के निर्माण के लिए प्रतिबंधित किया जा रहा है। अगर मुझे मौजूदा संरचना में बदलाव करने की ज़रूरत है तो मुझे लगता है कि मेरा ग्राहक प्रस्ताव को खारिज कर सकता है .. हालांकि अगर इसे सही करने का एकमात्र तरीका यह है कि मुझे ऐसा करना होगा।

मेरे पास एक आइटम टेबल है जो मुझे किसी भी तालिका से लिंक कर सकता है, और समय के साथ ये तालिकाएं बढ़ सकती हैं। आइटम केवल मुझे एक अन्य तालिका से जोड़ा जा सकता है, लेकिन दूसरी तालिका में रिकॉर्ड से जुड़े कई आइटम हो सकते हैं।

टेबल/संस्थाओं के उदाहरण जोड़ा जा रहा है करने के लिए Person, Vehicle, Building, Office हैं। ये सभी अलग टेबल हैं। आइटम की

उदाहरण Pen, Stapler, Cushion, Tyre, A4 Paper, Plastic Bag, Poster, Decoration"

उदाहरण एक Poster के लिए करने के लिए आवंटित किया जा सकता है एक Person या Office या Building। भविष्य में यदि वे Conference Room तालिका जोड़ते हैं तो इसे भी जोड़ा जा सकता है।

मेरे intital विचार कर रहे हैं:

Item 
{ 
    ID, 
    Name 
} 

LinkedItem 
{ 
    ItemID, 
    LinkedToTableName, 
    LinkedToID 
} 

LinkedToTableName क्षेत्र तो मुझे मेरे कोड में से जोड़ने के लिए सही तालिका की पहचान करने की अनुमति देगा।

मैं इस समाधान से अत्यधिक खुश नहीं हूं, लेकिन मैं कुछ और नहीं सोच सकता। कृपया सहायता कीजिए! :)

धन्यवाद!

Answer 1

तालिका नामों को कॉलम मानों के रूप में स्टोर करना एक अच्छा अभ्यास नहीं है। यह एक बुरा हैक है।

आप जो करने की कोशिश कर रहे हैं, उसके दो मानक तरीके हैं। पहले को सिंगल-टेबल विरासत कहा जाता है। यह आसानी से ओआरएम उपकरण द्वारा समझा जाता है लेकिन कुछ सामान्यीकरण से ट्रेड करता है। विचार यह है कि इन सभी इकाइयों - Person, Vehicle, जो कुछ भी - एक ही तालिका में संग्रहीत होते हैं, अक्सर भेदभावकर्ता फ़ील्ड के साथ कई प्रविष्टि कॉलम के साथ, जो यह पहचानता है कि इकाई किस प्रकार की है।

भेदभाव क्षेत्र आमतौर पर एक पूर्णांक प्रकार होता है, जो आपके कोड में कुछ गणना के लिए मैप किया जाता है। यह आपके डेटाबेस में कुछ लुकअप टेबल के लिए एक विदेशी कुंजी भी हो सकता है, यह पहचानने के लिए कि कौन से नंबर किस प्रकार से मेल खाते हैं ( तालिका नाम, केवल विवरण)।

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

पहले मामले में, विशिष्टता अंतर्निहित है, क्योंकि सभी संस्थाएं एक तालिका में हैं। दूसरे मामले में, संबंध Item और आधार इकाई आईडी के बीच है, जो विशिष्टता की भी गारंटी देता है।

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

एकाधिक-टेबल विरासत आपकी वर्तमान स्कीमा का एक करीबी मिलान है, इसलिए मैं इसे तब तक जाने की अनुशंसा करता हूं जब तक कि आपको इसे लिंक से SQL या इसी तरह के ORM के साथ उपयोग करने की आवश्यकता न हो।

यहां एक विस्तृत विस्तृत ट्यूटोरियल के लिए देखें: Implementing Table Inheritance in SQL Server।

Answer 2

आपकी लिंक तालिका ठीक है।

आपके पास जो समस्या होगी वह यह है कि आपको रनटाइम पर गतिशील एसक्यूएल उत्पन्न करने की आवश्यकता होगी। पैरामीटरयुक्त एसक्यूएल आम तौर पर सूची से पैरामीटर मानने वाली वस्तुओं को अनुमति नहीं देता है।

मैं इसे टालना चाहता हूं, आप आईडी को पकड़ने के लिए एक टेबल बनाकर थोड़ा कह सकते हैं (मान लें कि आईडी अन्य टेबलों में अद्वितीय हैं) और type_id दर्शाता है कि कौन सी तालिका स्रोत है, और एक उत्पन्न विवरण - उदाहरण के लिए आंतरिक रिकॉर्ड से नाम मूल्य।

आधार जानकारी संशोधित होने पर आप इस denormalized सूची के निर्माण को ट्रिगर करेंगे, और आप सामान्यीकृत प्रश्नों के लिए इसका उपयोग कर सकते हैं - और फिर रनटाइम पर आवश्यक होने पर आपके गतिशील प्रश्नों का सहारा लें।

Answer 3

व्यक्ति, वाहन, बिल्डिंग, कार्यालय के लिए कुछ आम का पता लगाएं। एक बेहतर अवधि की कमी के लिए मैंने इकाई का उपयोग किया है। फिर इकाई और उसके उप-प्रकारों के बीच सुपर-प्रकार/उप-प्रकार के संबंध लागू करें। ध्यान दें कि EntityID सभी उप-प्रकार तालिकाओं में PK और FK है। अब, आप आइटम तालिका इकाई (स्वामी) से लिंक कर सकते हैं। इस मॉडल में, एक आइटम केवल एक इकाई से संबंधित हो सकता है; एक इकाई (0) कई आइटम हो सकता है।