आप उदाहरण के लिए है, तो> 5 बाईं एक प्रश्न में मिलती है अपने डिजाइन के साथक्या बहुत से बाएं कोड गंध में शामिल हो गए हैं?
यह कुछ डिज़ाइनों के लिए एक बिल्कुल वैध समाधान है।
आप के एक पदानुक्रम है कहो एक-से-कई तरह Customer संबंधों - Order - Basket - Item - Price, आदि, जो किसी भी स्तर पर रिक्त जा सकता है: एक Customer कोई Orders हो सकता है, एक Order हो सकता है कोई
SELECT *
FROM Customer c
LEFT OUTER JOIN
Order o
ON o.CustomerID = c.ID
LEFT OUTER JOIN
Basket b
ON b.OrderID = c.ID
…
नोट यह कुछ मामलों में अक्षम हो सकता है, औरसाथ प्रतिस्थापित किया जा सकता है: Baskets, आदि
इस मामले में आप की तरह कुछ जारीया NOT EXISTS (यदि आप केवल यह जानना चाहते हैं कि संबंधित रिकॉर्ड मौजूद हैं या अन्य तालिकाओं में मौजूद नहीं हैं)।
प्रदर्शन जानकारी के लिए अपने ब्लॉग में इस लेख देखें:
NOT EXISTSमौजूदा तकनीक बनाम मौजूद नहीं है (जो मैं एक बड़ा प्रशंसक हूं) एक उत्कृष्ट बिंदु है, लेकिन फिर से जुड़ना सही हो सकता है। – annakata
निश्चित रूप से। यही कारण है कि मैंने "किसी भी कीमत पर प्रतिस्थापित किया जाना चाहिए और फिर कभी भी उपयोग नहीं किया जाना चाहिए" के बजाय "प्रतिस्थापित किया जा सकता है" :) – Quassnoi
साथ LEFT JOIN की जगह से लाभ यह है कि यह कुछ आप/मैं जांच करनी चाहिए सकता है हाँ कहो। ऐसा लगता है कि आप इससे कुछ विचारों को फैक्टर करके बेहतर उपयोगिता और रखरखाव प्राप्त कर सकते हैं।
इस अर्थ में कि यह "खराब कोड" नहीं है, यह काफी आसानी से उचित हो सकता है विशेष रूप से बड़े डीबी और आधुनिक डेटाबेस के लिए किसी भी अक्षमता को अनुकूलित करने की संभावना है।
नहीं, यह पूरी तरह से ठीक है, हालांकि यदि आप स्वयं को एक ही टेबल/ में समान जोड़ों का उपयोग करके एक ही प्रश्न/प्रक्रियाओं को बार-बार लिखते हैं, तो शायद यह आपको सरल बनाने के लिए एक दृश्य बनाने के लिए उम्मीदवार हो भविष्य में प्रश्न, और यदि आप स्कीमा बदलते हैं तो स्पर्श बिंदुओं की संख्या को कम करने के लिए आपको
कई बार आप सहायक विचार बनाकर दृश्य गंध को कम कर सकते हैं, मुझे नहीं लगता कि वहां एक है कठिन और तेज़ नियम कितने बाएं जुड़ने को बुरा माना जाता है।
प्रक्रियात्मक कोडिंग के विपरीत, छोटे बिट्स और टुकड़ों में एसक्यूएल को तोड़ने से अक्षम प्रश्न हो सकते हैं।
किसी के लिए इस तरह के सामान्य प्रश्न के उत्तर देने के लिए और इस तरह के मनमाना नियम बनाने का प्रयास करने के लिए यह बहुत असंभव है।
बाएं जुड़ने एक पूरी तरह से स्वीकार्य प्रकार के शामिल हैं जो एक बहुत ही सामान्य आवश्यकता पर नक्शा है: मुझे सभी एक्स प्राप्त करें, अगर वे वाई से जुड़े हैं तो उन्हें भी प्राप्त करें।
आपका परिणाम भिन्न हो मेरे साधारण से बाहर
कुछ भी कुछ भी करने के लिए एक कोड-गंध हो सकता है। Quassnoi की तरह कहा कि यह पूरी तरह से वैध हो सकता है। वास्तव में गहन रिपोर्ट के लिए यह असामान्य नहीं है कि जानकारी को सही तरीके से एक साथ टुकड़े करने के लिए पागल राशि की आवश्यकता हो। इसका मतलब यह नहीं है कि डेवलपर को अपने डेटाबेस को denormalizing देखना चाहिए।
नहीं, बिलकुल नहीं। डेटाबेस डिज़ाइन बनाने के लिए यह पूरी तरह से वैध है जो कुछ प्रश्नों पर बाएं जुड़ने की महत्वपूर्ण संख्या का उपयोग करता है।
यह कहकर कि मैं आमतौर पर डेटाबेस का निर्माण करना पसंद करता हूं ताकि बाहरी जोड़ों की आवश्यकता होने वाले मामलों की संख्या सीमित हो क्योंकि अनुभव (जटिल) प्रश्न जो उनका उपयोग करते हैं, वे अधिक त्रुटि प्रवण होते हैं और वृद्धि की संभावना होती है रखरखाव की समस्याओं के लिए।
एक दिलचस्प ऐतिहासिक तरफ के रूप में, आईबीएम के डीबी 2 के शुरुआती संस्करण, जब यह केवल मेनफ्रेम पर चलता था, बाहरी जुड़ने का समर्थन नहीं करता था (ओरेकल और इन दोनों ने उस समय एक प्रमुख बिक्री बिंदु था)। यह डेटाबेस डिज़ाइन में कुछ रोचक मुद्दों का कारण बनता है क्योंकि यह सुनिश्चित करना आवश्यक था कि डेटाबेस के लिए सभी अपेक्षित डेटा एक्सेस आवश्यकताएं केवल आंतरिक जुड़ने के जरिए हल की जा सकें।
मैं दलील दूंगा कि कई जोड़ों (जैसे सामान्यीकृत डेटा के साथ सौदा) का उपयोग करने के लिए कोड गंध नहीं है, बल्कि एक संकेत है कि आप सही जगह पर काम नहीं कर रहे हैं। मेरे अनुभव में, जो प्रश्नों में शामिल होने की संख्या के बारे में चिंतित हैं वे डेटाबेस में बहुत अधिक विकास कर रहे हैं और डेटा का पर्दाफाश करने वाले अनुप्रयोगों और रिपोर्टों में पर्याप्त नहीं हैं। डेटा संरचनाओं को असंख्य उपयोगों का समर्थन करने के लिए पर्याप्त लचीला होना चाहिए और यही कारण है कि सामान्यीकरण, एक डिग्री या दूसरे के लिए, महत्वपूर्ण है।
आज के एंटरप्राइज़ अनुप्रयोगों के निर्माण में, डेवलपर्स कम काम के साथ अधिक मूल्य प्रदान करने के लिए, एसक्यूएल, और यहां तक कि एक्सएमएल जैसी तकनीकों के ऊपर उच्च स्तर पर काम करने के लिए कल की उपलब्धियों का लाभ उठा सकते हैं। उपकरण हैं, यानी लेखक, कोड जनरेटर, ओआरएम, इकाई ढांचे, आदि रिपोर्ट करें, जो मैन्युअल रूप से एसक्यूएल बनाने के निम्न स्तर के काम को दूर करते हैं, और आपके लिए जुड़ेंगे। अधिकांश एसक्यूएल बोली का उपयोग किया जा रहा है (उदाहरण के लिए, ओरेकल 9 बनाम माईएसक्यूएल 3) से अवगत हैं और एसक्यूएल सिंटैक्स उत्पन्न कर सकते हैं जो उस बोली के लिए सबसे अधिक कुशल है; जिसका अर्थ है कि वे शायद आप से बेहतर जोड़ों को बना सकते हैं।
हालांकि, ये उपकरण पर्याप्त सामान्यीकरण के बिना एक रिलेशनल वातावरण में बहुत खराब या बिल्कुल काम नहीं करते हैं। मेरे लिए, यह वह जगह है जहां एक "विकास" गंध खुद प्रकट होती है; यदि एक स्थापित डेटा एक्सेस टूल उन संबंधों को समझ नहीं सकता है जिनके तहत मैंने अपना डेटा संरचित किया है, तो शायद मुझे उन रिश्तों को बनाने के लिए एक सामान्यीकृत तरीका तलाशने की आवश्यकता है और इसमें उपकरण के उपयोग से कहीं अधिक लाभ प्राप्त होते हैं। आम तौर पर, कहीं और 2 और 3 normal form के बीच मीठा स्थान है; हालांकि अनिवार्य रूप से संबंधपरक डेटा के छोटे क्षेत्र होते हैं जहां सामान्यीकरण की उच्च डिग्री समझ में आता है और मूल्य जोड़ता है।
चीयर्स, ट्रैविस
बहुत अच्छा जवाब श्रीमान। –
होना चाहिए समुदाय विकी – cjk
@ck - कोई ऐसा नहीं होना चाहिए; यह प्रश्न एक गैर-व्यक्तिपरक उत्तरदायी प्रश्न है। –
मेरा $ 0.02: जब तक आप ज्ञात प्रदर्शन समस्याओं तक नहीं पहुंच जाते हैं और पहले से ही आसान अनुकूलन समाप्त कर चुके हैं, तब तक "बहुत सामान्य" जैसी कोई चीज़ नहीं है। उस समय, यह कुछ बहुत ही नियंत्रित नहीं किया जा सकता है _controlled_ और _careful_ denormalization। – rmeador