अद्यतन 2009.04.24कई से अधिक रिश्तों: कॉलम में सहयोगी तालिका या सीमांकित मान का उपयोग करें?
मेरे सवाल का मुख्य बिंदु डेवलपर भ्रम और इसके बारे में क्या करने के लिए नहीं है।
बिंदु यह समझना है कि सीमित मूल्य सही समाधान कब हैं।
मैंने वाणिज्यिक उत्पाद डेटाबेस (Ektron lol) में उपयोग किए गए सीमित डेटा को देखा है।
एसक्यूएल सर्वर में एक एक्सएमएल डाटाटाइप भी है, ताकि इसका उपयोग सीमित क्षेत्रों के समान उद्देश्य के लिए किया जा सके।
/अंत अद्यतन
आवेदन मैं डिजाइनिंग कुछ कई-से-अनेक संबंध हैं। अतीत में, मैंने अक्सर डेटाबेस में इन्हें प्रस्तुत करने के लिए सहयोगी तालिकाओं का उपयोग किया है। इससे डेवलपर्स को कुछ भ्रम पैदा हुआ है।
यहाँ एक उदाहरण डीबी संरचना है:
Document
---------------
ID (PK)
Title
CategoryIDs (varchar(4000))
Category
------------
ID (PK)
Title
दस्तावेज़ और श्रेणी के बीच अनेक-से-अनेक संबंध नहीं है।
इस कार्यान्वयन में, Document.CategoryIDs श्रेणी आईडी की एक बड़ी पाइप-सीमित सूची है।
मेरे लिए, यह बुरा है क्योंकि इसे प्रश्नों में मिलान करने वाले पदार्थों के उपयोग की आवश्यकता होती है - जो इंडेक्स का उपयोग नहीं कर सकते हैं। मुझे लगता है कि यह धीमा हो जाएगा और स्केल नहीं होगा।
कि मॉडल के साथ, एक श्रेणी के लिए सभी दस्तावेज प्राप्त करने के लिए, आप की तरह कुछ की आवश्यकता होगी निम्नलिखित:
Document_Category
-------------------------------
DocumentID (PK)
CategoryID (PK)
यह:
select * from documents where categoryids like '%|' + @targetCategoryId + '|%'
मेरे समाधान के रूप में निम्नानुसार एक साहचर्य तालिका बनाने के लिए है डेवलपर्स को भ्रमित कर रहा है। क्या कोई सुरुचिपूर्ण वैकल्पिक समाधान है जो मुझे याद आ रहा है?
मुझे लगता है कि दस्तावेज में हजारों पंक्तियां होंगी। श्रेणी 40 पंक्तियों या उससे भी हो सकती है। प्राथमिक चिंता क्वेरी प्रदर्शन है। क्या मैं इसे अधिक इंजीनियरिंग कर रहा हूं?
क्या कोई ऐसा मामला है जहां डेटा को किसी सहयोगी तालिका में डेटा को धक्का देने के बजाय डेटाबेस कॉलम में आईडी की सूचियां संग्रहीत करना पसंद है?
यह भी विचार करें कि हमें दस्तावेज़ों के बीच कई से अधिक संबंध बनाने की आवश्यकता हो सकती है। यह एक सहयोगी तालिका Document_Document का सुझाव देगा। क्या यह पसंदीदा डिज़ाइन है या संबंधित कॉलम आईडी को एक कॉलम में स्टोर करना बेहतर है?
धन्यवाद।
मेरी कंपनी बड़े पैमाने पर सीएसवी कॉलम का उपयोग करती है। यह एक पूर्ण दुःस्वप्न है। यह बहुत बुरा है, उन्होंने इसे भी महसूस किया है और इसे रोकना बंद कर दिया है, लेकिन हमें अभी भी विरासत का समर्थन करना है :( – rmeador
मैं आपकी विधि से सहमत हूं, लेकिन यदि आप कॉलम नाम के रूप में "आईडी" का उपयोग नहीं करते हैं तो यह मदद कर सकता है। " दस्तावेज़ आईडी "और" श्रेणी आईडी "बेहतर हैं और फिर एफके के पास समान कॉलम नाम हो सकते हैं। –
सीमित मानों को स्वीकार्य माना जा सकता है यदि आपको किसी भी SQL कथन में सूची को विच्छेदन करने की आवश्यकता नहीं होती है, और कभी भी उन पर पूछताछ करने की आवश्यकता नहीं होती है। फिर भी, आमतौर पर आपके सहयोगी टेबल डिज़ाइन के साथ जाना बेहतर होगा। वैकल्पिक रूप से, मेरे उत्तर में, एक डीबीएमएस का उपयोग करें जो सूचियों को मूल रूप से संभालता है। –