क्या कभी ऐसा समय है जहां डेटाबेस 1: 1 संबंध का उपयोग करने से समझ में आता है?

162

मैं दूसरे दिन सामान्यीकरण पर सोच रहा था, और यह मेरे साथ हुआ, मैं उस समय के बारे में नहीं सोच सकता जहाँ एक डेटाबेस में 1: 1 संबंध होना चाहिए।

Name:SSN? मैं उन्हें एक ही टेबल में रखूंगा।
PersonID:AddressID? फिर से, वही टेबल।

मैं 1: कई या कई: कई (उपयुक्त मध्यवर्ती तालिकाओं के साथ) के एक ज़िलिन के उदाहरण के साथ आ सकता हूं, लेकिन कभी भी 1: 1 नहीं।

क्या मुझसे साफ़ - साफ़ कुछ चीज़ चूक रही है?

— Pulsehead
स्रोत

डेटाबेस को कई भौतिक उपकरणों में विभाजित करना आसान होता है जब इसे इस तरह अलग किया जाता है।

— पचेरियर

और एक फॉलोअप सवाल, अगर यह समझ में आता है, यह कैसे करना है? यहाँ और यहाँ माना जाता है - मेरा सवाल यह है कि 2 कुंजी में से किसका चयन करना है विदेशी कुंजी बाधा? मुझे लगता है कि यह इस बात पर निर्भर करता है कि आप किस उपयोग-मामले को संबोधित करने का प्रयास कर रहे हैं ...

— रेड मटर

161

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

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

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

जब भी आपके पास एक बड़ी इकाई के सुसंगत उपसमुच्चय की आवश्यकता होती है, तो भौतिक विभाजन उपयोगी हो सकता है ।

— Godeke
स्रोत

32

इसका एक आदर्श उदाहरण एक तालिका हो सकती है जिसमें फाइलें शामिल हैं। आप (स्पष्ट कारणों के लिए) एक तालिका रखना चाहते हैं जिसमें केवल फ़ाइल का मेटा डेटा (फ़ाइल नाम, माइम प्रकार, आदि) और एक अन्य तालिका है, मैप किए गए 1: 1, जिसमें वास्तविक बूँद डेटा शामिल है। यह कुछ उदाहरणों में फ़ाइलों की क्वेरी / छँटाई में ओवरहेड को कम करेगा।

— केविन पेनो

2

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

— गोडके

@Ochado जबकि मैं मानता हूं कि आपके पास 1: 1 के लिए कई स्वाभाविक रूप से होने वाले (गैर-भौतिक) कारण हैं, "यदि आपके पास ऐतिहासिक जानकारी नहीं है" तो उन मामलों को बनाता है जो मैं शायद 1: 1 के संबंध का उपयोग नहीं करता। लागू करते हैं।

— गोडके

1

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

— गोडके

वास्तव में, आईएस-ए और मिलान आरक्षण परिदृश्यों की संभावना 1: 1 रहेगी, भले ही ऐतिहासिक डेटा संग्रहीत हो।

— त्रिपक्षीयियो

125

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

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

इसके बारे में मेरा ब्लॉग प्रविष्टि।

— kemiller2002
स्रोत

47

विरल थी। डेटा संबंध तकनीकी रूप से 1: 1 हो सकता है, लेकिन संबंधित पंक्तियों को प्रत्येक पंक्ति के लिए मौजूद नहीं होना चाहिए। इसलिए यदि आपके पास बीस मिलियन पंक्तियाँ हैं और कुछ मान हैं जो केवल 0.5% के लिए मौजूद हैं, तो अंतरिक्ष की बचत बहुत बड़ी है यदि आप उन स्तंभों को एक तालिका में बाहर धकेलते हैं जो बहुत कम आबादी वाले हो सकते हैं।

— अराजकता
स्रोत

8

"लेकिन संबंधित पंक्तियों को प्रत्येक पंक्ति के लिए मौजूद नहीं होना है" फिर यह 1: 1 नहीं है। आप 1: 0,1 की बात कर रहे हैं।

1

हाँ। अगर ओपी ने भेद निकाला तो डन्नो

— अराजकता

2

ठीक है, मुझे लगता है कि उन्होंने किया क्योंकि 1: 0,1 में आपके बहुत सारे उपयोग हैं, लेकिन 1: 1 बहुत कम है। और वे उपयोग करने के लिए संघर्ष कर रहे थे, इसलिए मैं कहूंगा कि ओपी भेद आकर्षित कर रहा था।

12

मेरी काम करने की धारणा इसके विपरीत थी क्योंकि उसने 1: 1, 1: कई, और कई: कई का उल्लेख किया था 1: 0-2.1 का उल्लेख किए बिना।

— अराजकता

26

उच्च रैंक वाले अधिकांश उत्तर 1: 1 रिश्तों के लिए बहुत उपयोगी डेटाबेस ट्यूनिंग और अनुकूलन कारण देते हैं, लेकिन मैं "जंगली" उदाहरणों में कुछ भी नहीं बल्कि "1: 1 संबंध" पर स्वाभाविक रूप से ध्यान केंद्रित करना चाहता हूं।

कृपया इन अधिकांश उदाहरणों के डेटाबेस कार्यान्वयन की एक महत्वपूर्ण विशेषता पर ध्यान दें: 1: 1 संबंध के बारे में कोई ऐतिहासिक जानकारी नहीं रखी गई है। यही है, ये रिश्ते समय में किसी भी बिंदु पर 1: 1 हैं। यदि डेटाबेस डिज़ाइनर समय के साथ रिलेशनशिप प्रतिभागियों में बदलाव दर्ज करना चाहता है, तो रिश्ते 1: M या M: M हो जाते हैं; वे अपना 1: 1 स्वभाव खो देते हैं। उस समझ के साथ, यहाँ जाता है:

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

मैं पहले किए गए कैविएट को दोहराता हूं कि इनमें से अधिकांश 1: 1 संबंध हैं केवल अगर कोई ऐतिहासिक जानकारी दर्ज नहीं की गई है। इसलिए, यदि कोई कर्मचारी किसी संगठन में अपनी भूमिका बदलता है, या एक प्रबंधक एक अलग विभाग की जिम्मेदारी लेता है, या एक कर्मचारी को एक वाहन को फिर से सौंपा जाता है, या किसी को विधवा और पुनर्विवाह किया जाता है, तो संबंध प्रतिभागी बदल सकते हैं। यदि डेटाबेस इन 1: 1 रिश्तों के बारे में किसी भी पिछले इतिहास को संग्रहीत नहीं करता है, तो वे 1: 1 रिश्तों के वैध बने रहते हैं। लेकिन अगर डेटाबेस ऐतिहासिक जानकारी दर्ज करता है (जैसे प्रत्येक रिश्ते के लिए प्रारंभ और समाप्ति तिथियां जोड़ना), तो वे बहुत अधिक एम: एम रिश्तों में बदल जाते हैं।

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

— Tripartio
स्रोत

2

मुझे वास्तव में पसंद है कि आप इस तरह के संबंध के सही होने पर मूल प्रश्न की भावना से कैसे चिपके हुए हैं और यह तब नहीं है जब यह कंप्यूटर की भौतिक प्रकृति जैसे सांसारिक कारणों से उपयोगी है।

— user1852503

21

आपके प्रश्न की व्याख्या कई तरीकों से की जा सकती है, क्योंकि आपने इसे जिस तरह से लिखा है। प्रतिक्रियाएं यह दिखाती हैं।

वास्तविक दुनिया में डेटा आइटमों के बीच निश्चित रूप से 1: 1 संबंध हो सकते हैं। इसके बारे में कोई सवाल नहीं। "एक" संबंध आम तौर पर एक से एक है। एक कार एक वाहन है। एक कार एक वाहन है। एक वाहन एक कार हो सकती है। कुछ वाहन ट्रक हैं, इस मामले में एक वाहन एक कार नहीं है। कई उत्तर इस व्याख्या को संबोधित करते हैं।

लेकिन मुझे लगता है कि आप वास्तव में जो पूछ रहे हैं वह है ... जब 1: 1 रिश्ते मौजूद हैं, क्या तालिकाओं को कभी विभाजित किया जाना चाहिए? दूसरे शब्दों में, क्या आपके पास कभी दो टेबल होनी चाहिए जिसमें बिल्कुल समान चाबियाँ हों? व्यवहार में, हम में से अधिकांश केवल प्राथमिक कुंजी का विश्लेषण करते हैं, और अन्य उम्मीदवार कुंजी नहीं, लेकिन यह सवाल थोड़ा अलग है।

1NF, 2NF और 3NF के लिए सामान्यीकरण नियमों को कभी भी एक ही प्राथमिक कुंजी के साथ दो तालिकाओं में तालिका को विघटित (विभाजित) करने की आवश्यकता नहीं होती है। मैंने काम नहीं किया है कि क्या बीसीएनएफ, 4 एनएफ, या 5 एनएफ में स्कीमा डालने से कभी-कभी एक ही कुंजी के साथ दो तालिकाओं में परिणाम हो सकता है। मेरे सिर के ऊपर से, मैं अनुमान लगाने जा रहा हूं कि उत्तर नहीं है।

सामान्यीकरण का एक स्तर है जिसे 6NF कहा जाता है। 6NF के लिए सामान्यीकरण नियम निश्चित रूप से एक ही प्राथमिक कुंजी के साथ दो तालिकाओं में परिणाम कर सकता है। 6NF में 5NF से अधिक लाभ है कि NULLS को पूरी तरह से टाला जा सकता है। यह कुछ के लिए महत्वपूर्ण है, लेकिन सभी नहीं, डेटाबेस डिजाइनर। मैंने कभी भी स्कीमा को 6NF में डालने की जहमत नहीं उठाई।

6NF में गुम डेटा को किसी कॉलम में NULL वाली पंक्ति के बजाय एक लोप की गई पंक्ति द्वारा दर्शाया जा सकता है।

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

— वाल्टर मिती
स्रोत

19

मैं उन्हें मुख्य रूप से कुछ कारणों से उपयोग करता हूं। डेटा परिवर्तन की दर में एक महत्वपूर्ण अंतर है। मेरी कुछ तालिकाओं में ऑडिट ट्रेल्स हो सकते हैं जहां मैं पिछले संस्करणों के रिकॉर्ड को ट्रैक करता हूं, अगर मुझे केवल 10 कॉलमों में से 5 के पिछले संस्करणों को ट्रैक करने की परवाह है, तो उन 5 कॉलमों को एक अलग टेबल पर ऑडिट ट्रेल तंत्र के साथ विभाजित करना अधिक कुशल है। इसके अलावा, मेरे पास रिकॉर्ड (एक लेखांकन ऐप के लिए कह सकते हैं) जो केवल लिखे गए हैं। आप डॉलर की मात्रा, या वे जिस खाते के लिए थे, उसे बदल नहीं सकते हैं, अगर आपने गलती की है तो आपको गलत रिकॉर्ड को समायोजित करने के लिए लिखने के लिए संबंधित रिकॉर्ड बनाने की आवश्यकता है, फिर एक सुधार प्रविष्टि बनाएं। मेरे पास इस तथ्य को लागू करने में बाधा है कि उन्हें अद्यतन या हटाया नहीं जा सकता है, लेकिन मेरे पास उस वस्तु के लिए कुछ विशेषताएँ हो सकती हैं जो निंदनीय हैं, उन लोगों को संशोधन के प्रतिबंध के बिना एक अलग तालिका में रखा जाता है। दूसरी बार जब मैं ऐसा करता हूं तो मेडिकल रिकॉर्ड में होता है। एक यात्रा से संबंधित डेटा है जिसे एक बार साइन इन करने के बाद नहीं बदला जा सकता है, और एक यात्रा से संबंधित अन्य डेटा जो साइनऑफ़ के बाद बदला जा सकता है। उस स्थिति में मैं डेटा को विभाजित करूँगा और बंद किए गए टेबल पर अद्यतनों को अस्वीकार करते हुए लॉक किए गए टेबल पर ट्रिगर लगा दूंगा, लेकिन डेटा को अपडेट करने की अनुमति डॉक्टर बंद साइन नहीं कर रहा है।

एक और पोस्टर पर टिप्पणी की गई 1: 1 सामान्य नहीं किया जा रहा है, मैं कुछ स्थितियों में, विशेष रूप से उपप्रकार से असहमत हूं। मान लीजिए कि मेरे पास एक कर्मचारी तालिका है और प्राथमिक कुंजी उनका SSN है (यह एक उदाहरण है, चलिए इस बहस को बचाते हैं कि क्या यह एक अच्छी कुंजी है या दूसरे धागे के लिए नहीं)। कर्मचारी विभिन्न प्रकार के हो सकते हैं, अस्थायी या स्थायी कह सकते हैं और यदि वे स्थायी हैं, तो उनके पास कार्यालय फ़ील्ड नंबर जैसे भरे जाने वाले अधिक क्षेत्र हैं, जो केवल टाइप = 'स्थायी' होने पर शून्य नहीं होना चाहिए। तृतीय सामान्य रूप के डेटाबेस में कॉलम केवल कुंजी पर निर्भर होना चाहिए, जिसका अर्थ कर्मचारी है, लेकिन यह वास्तव में कर्मचारी और प्रकार पर निर्भर करता है, इसलिए 1: 1 संबंध पूरी तरह से सामान्य है, और इस मामले में वांछनीय है। यह सामान्य रूप से भरे जाने वाले 10 स्तंभों को रोकता है, यदि मेरे पास 10 कॉलम हैं, जो सामान्य रूप से भरे हुए हैं,

— शेन डेलमोर
स्रोत

1

@ShenD +1 वास्तविक शब्द उदाहरण के लिए। मुझे "रीड ओनली" भेद भी पसंद है।

— माइकल रिले -

13

सबसे आम परिदृश्य मैं सोच सकता हूँ जब आपके पास BLOB है। मान लें कि आप एक डेटाबेस में बड़ी छवियां संग्रहीत करना चाहते हैं (आमतौर पर, उन्हें संग्रहीत करने का सबसे अच्छा तरीका नहीं है, लेकिन कभी-कभी बाधाएं इसे बहुत सुविधाजनक बनाती हैं)। आप आमतौर पर चाहते हैं कि गैर-बूँद डेटा के लुकअप को बेहतर बनाने के लिए बूँद अलग तालिका में हो।

— एरिक फ़नकेनबस
स्रोत

गंभीरता से? आमतौर पर सबसे अच्छा तरीका नहीं है? एक डेटाबेस में एकल सबसे बड़ा ऑनलाइन संगीत विक्रेता स्टोर, अहम, एमपी 3 है।

1

@Mark, छवियों को संग्रहीत करने के सर्वोत्तम तरीके से निपटने के लिए कुछ प्रश्न हैं, या तो डेटाबेस या आउट में, और सर्वसम्मति से लगता है कि अधिकांश भाग के लिए फ़ाइल सिस्टम तेज़ है। मुझे लगता है कि अगर यह वास्तव में सच है, तो एमपी 3 के लिए भी यही सच होगा।

— जेम्स मैकमोहन

1

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

— ब्लिसप्रॉप

1

यह तर्कपूर्ण है कि क्या डेटाबेस में बड़े डेटा (फ़ाइलों) को स्टोर करने के लिए समझ में आता है, कुछ इसके लिए हैं सभी के पास वैध कारण हैं, लेकिन 1: 1 के उदाहरण के लिए +1।

— केविन पेनो

यह वास्तव में अपना प्रश्न होना चाहिए जिसे मैं देखना चाहूंगा। स्मार्ट लोगों से इनपुट के साथ जो विभिन्न हार्डड्राइव / ओएस / आरडीबीएमएस के लिए समय / प्रेस्टैंडा को मापते हैं। इस सवाल का एक निश्चित जवाब होना चाहिए, अगर सही तरीके से मापा जाए तो यह तर्क संगत नहीं होना चाहिए। क्या यह किसी ने भी नहीं किया है?

— स्टेफान

9

शुद्ध विज्ञान के संदर्भ में, हाँ, वे बेकार हैं।

वास्तविक डेटाबेस में कभी-कभी उपयोग किए जाने वाले फ़ील्ड को एक अलग तालिका में रखना कभी-कभी उपयोगी होता है: यह और केवल इस फ़ील्ड का उपयोग करके प्रश्नों को गति देने के लिए; ताले आदि से बचने के लिए।

— Quassnoi
स्रोत

3

@Mark ब्रैडी: नहीं, ऐसा नहीं है, क्योंकि Na2SO4 और KCl हैं। एक ब्रह्मांड डेटाबेस बनाते समय, आपको t_atom (id INT, protons INT, न्यूट्रॉन INT), t_molecule (id INT, atom_id INT) बनाना चाहिए और जॉइन करना चाहिए। यह एक-से-एक रिश्ता है।

— क्वासोनी

2

एक दूसरे विचार में, INT यहां पर्याप्त नहीं हो सकता है, क्योंकि ब्रह्मांड में 10 ^ 78 परमाणु हैं। यहां तक कि दो GUID एक साथ परमाणुओं के केवल 1/10 वें भाग को पकड़ सकते हैं। हमें एक RAW (40) प्राथमिक कुंजी की आवश्यकता होगी - बस अगर हमारा डेटाबेस बहुत तेजी से बढ़ेगा। डार्क मैटर, तुम्हें पता है, कुछ का।

— क्वासोइ

1

ओह, इसलिए केवल संबंधपरक सिद्धांत ही शुद्ध विज्ञान है। जब तक हम इसके लिए एक डेटाबेस का निर्माण नहीं किया था कि रसायन विज्ञान एक शुद्ध विज्ञान नहीं था एहसास नहीं था।

1

@ मार्की ब्रैडी: क्या आप कृपया यह नहीं कह सकते कि आप किससे सहमत नहीं हैं? मुझे आपका व्यंग्य नहीं आता, वास्तव में :)

— १

Quassnoi (और मार्क ब्रैडी) आपको मेरे द्वारा दिए गए LOL के लिए अपवोट मिलता है।

— पल्सहेड

8

खेतों तक पहुंच को प्रतिबंधित करने के लिए विचारों का उपयोग करने के बजाय, यह कभी-कभी प्रतिबंधित क्षेत्रों को एक अलग तालिका में रखने के लिए समझ में आता है, जिसमें केवल कुछ उपयोगकर्ताओं की पहुंच होती है।

— eleven81
स्रोत

8

मैं उन स्थितियों के बारे में भी सोच सकता हूं, जहां आपके पास एक ओओ मॉडल है जिसमें आप विरासत का उपयोग करते हैं, और विरासत के पेड़ को डीबी के अनुरूप होना चाहिए।

उदाहरण के लिए, आपके पास एक क्लास बर्ड और फिश है, जो दोनों को एनिमल से विरासत में मिली है। आपके DB में आपके पास एक 'पशु' तालिका हो सकती है, जिसमें पशु वर्ग के सामान्य क्षेत्र शामिल हैं, और पशु तालिका में बर्ड टेबल के साथ वन-टू-वन संबंध है, और मछली के साथ एक-से-एक संबंध है तालिका।

इस स्थिति में, आपके पास एक पशु तालिका नहीं है, जिसमें बर्ड और फिश-प्रॉपर्टीज़ को रखने के लिए बहुत सारे अशक्त स्तंभ शामिल हैं, जहाँ सभी कॉलम जिनमें फिश-डेटा होता है, जब रिकॉर्ड बर्ड का प्रतिनिधित्व करता है, तो इसे NULL पर सेट किया जाता है।

इसके बजाय, आपके पास बर्ड्स-टेबल में एक रिकॉर्ड है जो पशु तालिका में रिकॉर्ड के साथ एक-से-एक संबंध रखता है।

— फ्रेडरिक घीसेल्स
स्रोत

यह उत्तर एक अन्य प्रश्न से संबंधित है: 1 से 0 relation1 संबंध।

— हिबू ५ H

8

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

— HLGEM
स्रोत

6

यह एक तालिका का विस्तार करने का एक तरीका भी है जो पहले से ही "वास्तविक" डेटाबेस परिवर्तन की तुलना में कम (कथित) जोखिम के साथ उत्पादन में है। एक विरासत प्रणाली में 1: 1 संबंध देखना अक्सर एक अच्छा संकेतक होता है कि प्रारंभिक डिजाइन के बाद खेतों को जोड़ा गया था।

— JT Grimes
स्रोत

क्यों समान है? क्या आपको लगता है कि किसी ब्रांड की नई टेबल में मौजूदा टेबल को बदलने जितना जोखिम है। कृपया उन चीज़ों को सूचीबद्ध करें जो नए तालिकाओं को जोड़ने पर टूटती हैं। केवल एक चीज जो मैं सोच सकता हूं वह कोड है जो मेटाडेटा से अधिक का चयन करता है अर्थात USER_TABLES लूप से <कुछ> एंड लूप।

1

यह कम है कि चीजें इससे टूट जाएंगी कि अक्सर एक अतिरिक्त क्षेत्र को जोड़ने की तुलना में 1: 1 तालिका को ठीक से जोड़ने में अधिक काम लगता है। अब एक नए रिकॉर्ड का मतलब सिर्फ एक के बजाय दो टेबल को अपडेट करना है। कोई रिकॉर्ड हटाना? साथ ही दो सवाल। अब हम इसे एक बार बदलने के बजाय अधिक कोड बनाए रख रहे हैं।

— JT Grimes

@Mark ब्रैडी, दृढ़ता से टाइप किए गए डेटासेट डेटाबेस में कुछ जोड़े को जोड़ते समय प्रबंधित करने के लिए एक नरक हो सकते हैं। यदि डेटासेट में एक टैब्लेडेप्टर में कई क्वेरी और इतने पर हैं, तो इसकी अधिक आसान बस नई तालिका में खींचें और फिर इसे किया जाता है।

— स्टीफन

@Stefan: कोई कैस्केड सम्मिलित नहीं है।

— JT Grimes

@Boofus, ठीक है .. कभी-कभी हमें कीबोर्ड का उपयोग करना पड़ता है और हम जो पैसा कमाते हैं उसके लिए थोड़ा प्रोग्राम करते हैं। ;)

— स्टीफन

5

एसक्यूएल में दो तालिकाओं के बीच 1: 1 संबंध को लागू करना असंभव है जो दोनों पक्षों पर अनिवार्य है (जब तक कि तालिका केवल-पढ़ने के लिए न हो)। अधिकांश व्यावहारिक उद्देश्यों के लिए SQL में "1: 1" संबंध वास्तव में 1: 0 | 1 का अर्थ है।

संदर्भ संबंधी बाधाओं में अनिवार्य कार्डिनैलिटी का समर्थन करने में असमर्थता SQL की गंभीर सीमाओं में से एक है। "डिफ्रैबल" बाधाओं की वास्तव में गणना नहीं की जाती है क्योंकि वे सिर्फ यह कहने का एक तरीका है कि बाधा को कुछ समय के लिए लागू नहीं किया जाता है।

— nvogel
स्रोत

4

यदि आप लोकप्रिय ORM में से किसी एक के साथ डेटा का उपयोग कर रहे हैं, तो आप अपने ऑब्जेक्ट हस्कर्मी से मिलान करने के लिए एक टेबल को कई तालिकाओं में तोड़ सकते हैं।

— जेसन पुण्यन
स्रोत

3

दुखद, दुखद कारण। यदि कोई ORM ऑब्जेक्ट मॉडल और भौतिक संग्रहण के बीच एक विचलन को संभाल नहीं सकता है तो .... बस दुखी।

दरअसल, अगर मैं सही तरीके से समझूं तो इसका मतलब रिलेशनल डेटाबेस में वर्गीकरण उत्तराधिकारियों को लागू करना है। यह 1: 1 रिश्तों का एक बिल्कुल वैध और प्राकृतिक मामला है; इसके बारे में "उदास" कुछ भी नहीं है।

— त्रियूपी

4

मैंने पाया है कि जब मैं एक 1: 1 संबंध पूरी तरह से एक व्यवस्थित कारण के लिए करता हूं, एक संबंधपरक कारण नहीं।

उदाहरण के लिए, मैंने पाया है कि उपयोगकर्ता के आरक्षित पहलुओं को 1 तालिका में रखना और उपयोगकर्ता के संपादन योग्य फ़ील्ड को एक अलग तालिका में रखना उन क्षेत्रों पर अनुमतियों के बारे में तार्किक रूप से उन नियमों को लिखने की अनुमति देता है जो बहुत आसान हैं।

लेकिन आप सही हैं, सिद्धांत रूप में, 1: 1 रिश्ते पूरी तरह से वंचित हैं, और लगभग एक घटना है। हालांकि तार्किक रूप से यह डेटाबेस को आसान बनाने वाले कार्यक्रमों और अनुकूलन को आसान बनाता है।

— DevelopingChris
स्रोत

घटना: वैज्ञानिक हित का कोई भी तथ्य या घटना है जिसे वैज्ञानिक रूप से वर्णित और / या समझाया जाने की संभावना है। मुझे नहीं लगता कि आप उस शब्द का उपयोग करना चाहते थे।

1

मुझे इसका उपयोग करने का मतलब था, इसके अर्थ में, एक दुर्लभ चीज होने का। आमतौर पर घटना का उपयोग आउटलेर्स का वर्णन करने के लिए किया जाता है, भले ही इसकी परिभाषा, मेरी पोस्ट के प्रत्येक शब्द को सही करने की आपकी बहुत आवश्यकता को परिभाषित करती है।

— विकासशील

@DevelopingChris मैं मानता हूं कि 1: 1 एक फ़िनोमेनसोन है। स्कूल सिद्धांत को छोड़कर बहुत कम वास्तविक विश्व स्थितियां हैं।

— माइकल रिले -

4

ज्यादातर समय, डिजाइनों को 1: 1 माना जाता है जब तक कि कोई व्यक्ति "अच्छी तरह से नहीं पूछता है, तो यह 1: कई क्यों नहीं हो सकता है"? समय से पहले एक दूसरे से अवधारणाओं को तलाक देना इस सामान्य परिदृश्य की प्रत्याशा में किया जाता है। व्यक्ति और पता इतने कसकर नहीं बाँधते हैं। बहुत सारे लोगों के कई पते हैं। और इसी तरह...

आमतौर पर दो अलग-अलग ऑब्जेक्ट स्पेस का मतलब है कि एक या दोनों को गुणा किया जा सकता है (x: many)। यदि दो वस्तुएं वास्तव में, वास्तव में 1: 1, यहां तक कि दार्शनिक रूप से हैं, तो यह एक रिश्ते से अधिक है। ये दो "वस्तुएं" वास्तव में एक संपूर्ण वस्तु के हिस्से हैं।

— मार्क कैनलास
स्रोत

3

विस्तारित जानकारी जो केवल कुछ परिदृश्यों में आवश्यक है। विरासत अनुप्रयोगों और प्रोग्रामिंग भाषाओं में (जैसे कि आरपीजी) जहां कार्यक्रम तालिकाओं के ऊपर संकलित किए जाते हैं (इसलिए यदि तालिका में परिवर्तन होता है तो आपको कार्यक्रम को पुनः प्राप्त करना होगा)। फाइलों के साथ टैग उन मामलों में भी उपयोगी हो सकता है, जहां आपको तालिका आकार के बारे में चिंता करनी होगी।

— रयान गिल
स्रोत

2

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

केवल तार्किक विचार जो 1-1 संबंध को निर्धारित करता है, जब कुछ विशेषताएं केवल कुछ संस्थाओं पर लागू होती हैं। हालांकि, ज्यादातर मामलों में इकाई निष्कर्षण के माध्यम से डेटा को मॉडल करने का एक बेहतर / अधिक सामान्यीकृत तरीका है।

— JohnFx
स्रोत

2

1: 1 संबंध के लिए मैं जो सबसे अच्छा कारण देख सकता हूं वह है डेटाबेस डिज़ाइन का सुपर टाइप सबटाइप। मैंने इस मॉडल के आधार पर एक रियल एस्टेट एमएलएस डेटा संरचना बनाई। पांच अलग-अलग डेटा फीड थे; आवासीय, वाणिज्यिक, मल्टीफ़ैमिली, होटल और भूमि।

मैंने एक SuperType नामक प्रॉपर्टी बनाई जिसमें डेटा था जो पाँच अलग-अलग डेटा फीड में से प्रत्येक के लिए सामान्य था। इसने सभी डेटाैटिप्स पर बहुत तेज़ "सरल" खोजों की अनुमति दी।

मैं पांच अलग-अलग सबटाइप बनाता हूं, जो प्रत्येक पांच डेटा फीड के लिए अद्वितीय डेटा तत्वों को संग्रहीत करता है। प्रत्येक सुपरटाइप रिकॉर्ड में उपयुक्त सबटाइप रिकॉर्ड के लिए 1: 1 संबंध था।

यदि कोई ग्राहक एक विस्तृत खोज चाहता था, तो उन्हें प्रॉपर्टी के लिए सुपर-उप प्रकार का चयन करना होगा।

— माइकल रिले - उर्फ गनी
स्रोत

1

मेरी राय में 1: 1 संबंध एक RDBMS पर एक वर्ग विरासत का नक्शा बनाता है। एक तालिका ए है जिसमें सामान्य विशेषताएँ शामिल हैं, यानी आंशिक वर्ग की स्थिति प्रत्येक विरासत में मिली कक्षा की स्थिति को RDBMS पर 1: 1 तालिका के साथ A तालिका के साथ मैप किया जाता है, जिसमें विशेष गुण होते हैं। तालिका नामांक A में एक "प्रकार" फ़ील्ड भी है जो "कास्टिंग" कार्यक्षमता का प्रतिनिधित्व करता है

बाय मारियो

1

यदि कोई महत्वपूर्ण प्रदर्शन लाभ है, तो आप एक से एक संबंध तालिका बना सकते हैं। आप शायद ही कभी उपयोग किए गए फ़ील्ड को अलग तालिका में डाल सकते हैं।

— KTA
स्रोत

0

1: 1 रिश्ते वास्तव में कोई मतलब नहीं रखते हैं यदि आप सामान्यीकरण में हैं, तो 1: 1 को उसी तालिका में रखा जाएगा।

हालांकि वास्तविक दुनिया में, यह अक्सर अलग होता है। आप अपने एप्लिकेशन इंटरफ़ेस से मिलान करने के लिए अपना डेटा तोड़ सकते हैं।

— Eppz
स्रोत

मैं एक तालिका सिद्धांत से असहमत हूं। ऐसे समय होते हैं जब 1: 1 रिश्तों के साथ एक सुपरटेप सबटाइप संबंध सबसे अच्छा व्यक्त किया जाता है।

— माइकल रिले - AKA Gunny

1

वास्तव में, यदि आप अत्यधिक सामान्यीकरण के लिए गए थे तो आपके पास बहुत अधिक 1: 1 रिश्ते होंगे। दिनांक द्वारा प्रस्तावित सामान्यीकरण के प्रारंभिक रूपों में यह नियम शामिल था कि किसी भी कॉलम को NULL की अनुमति नहीं देनी चाहिए। इसका मतलब था कि यदि कोई स्तंभ किसी तालिका के लिए NULL हो सकता है, तो वह अपनी तालिका में होना चाहिए और एक पंक्ति केवल तभी जोड़ी जानी चाहिए जब उसका मूल्य हो। इस नियम को ज्यादातर कोडेड द्वारा त्याग दिया गया है।

— टॉम एच

0

संभवतः यदि आपके डेटाबेस में किसी प्रकार की टाइप की हुई वस्तुएं हैं।

एक तालिका में कहें, टी 1, आपके पास एक से एक संबंध के साथ कॉलम सी 1, सी 2, सी 3 ... हैं। यह ठीक है, यह सामान्यीकृत रूप में है। अब एक टेबल T2 में कहें, आपके पास कॉलम C1, C2, C3, ... (नाम भिन्न हो सकते हैं, लेकिन कहते हैं कि प्रकार और भूमिका समान होती है) एक से एक संबंध भी। यह T1 के समान ही कारणों से T2 के लिए ठीक है।

इस मामले में, हालांकि, मैं C1, C2, C3… और T1 से T3 और T2 से T3 के लिए एक संबंध रखने वाले एक अलग टेबल T3 के लिए एक फिट देखता हूं। मैं और भी अधिक एक फिट देखता हूं यदि कोई अन्य तालिका मौजूद है, जिसके साथ पहले से ही एक से कई C1, C2, C3 मौजूद हैं ... तालिका A से तालिका A में एकाधिक पंक्तियों के लिए कहें। तो, T3 के बजाय, आप B का उपयोग करते हैं, और है T1 से B के लिए एक से एक संबंध, T2 से B के लिए समान, और फिर भी A से B के लिए एक से एक से अधिक संबंध हैं।

मेरा मानना है कि सामान्यीकरण इससे सहमत नहीं है, और इसके बाहर एक विचार हो सकता है: ऑब्जेक्ट प्रकारों की पहचान करना और एक ही प्रकार की वस्तुओं को अपने स्वयं के भंडारण पूल में ले जाना, कुछ तालिकाओं से एक से एक संबंध का उपयोग करना, और एक से कई कुछ अन्य तालिकाओं से संबंध।

— Hibou57
स्रोत

0

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

उदाहरण:

 Citizen Table
 id = 1, citizen_name = "EvryBod"
 id = 2, citizen_name = "Lesly"
 id = 3, citizen_name = "Wasserman"

 Candidate Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"

फिर, यदि हम मतदान तालिका देखते हैं:

 Voting Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"
 id = 4, citizen_id = 3, candidate_name = "Hill Arry"
 id = 5, citizen_id = 3, candidate_name = "Hill Arry"

हम कह सकते हैं कि नागरिक संख्या 3 आग पर झूठा पैंट है जिसने बर्न नी को धोखा दिया। बस एक उदाहरण है।

— लेसली रिवेंज
स्रोत

0

जब आप किसी तीसरे पक्ष के उत्पाद से डेटाबेस के साथ काम कर रहे होते हैं, तो आप शायद अपने डेटाबेस को बदलना नहीं चाहते हैं ताकि तंग युग्मन को रोका जा सके। लेकिन आपके पास डेटा हो सकता है जो उनके डेटा के साथ 1: 1 से मेल खाता हो

— symbiont
स्रोत

-4

कहीं भी दो पूरी तरह से स्वतंत्र संस्थाएं एक-से-एक संबंध साझा करती थीं। बहुत सारे उदाहरण होने चाहिए:

व्यक्ति <-> दंत चिकित्सक (इसके 1: एन, इसलिए यह गलत है!)

व्यक्ति <-> डॉक्टर (इसका 1: N है, इसलिए यह भी गलत है!)

व्यक्ति <-> पति / पत्नी (इसका 1: 0 | 1, इसलिए इसका ज्यादातर गलत है!)

संपादित करें: हाँ, वे बहुत बुरे उदाहरण थे, खासकर अगर मैं हमेशा 1: 1 की तलाश में था, दोनों ओर 0 या 1 नहीं। मुझे लगता है कि मेरा दिमाग गलत तरीके से गोलीबारी कर रहा था :-)

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

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

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

प्रत्येक मामले में आप अलग-अलग संस्थाओं को एक बड़े रिकॉर्ड के रूप में पेश कर सकते हैं, लेकिन विघटन के स्तर को देखते हुए, यह गलत होगा। वे इन विशिष्ट संदर्भों में, वास्तव में स्वतंत्र संस्थाएं हैं, हालांकि वे उच्च स्तर पर प्रकट नहीं हो सकते हैं।

पॉल।

— पॉल डब्ल्यू होमर
स्रोत

एक दंत चिकित्सक पर एक रोगी है? एक डॉक्टर के पास केवल एक रोगी है? केवल 1: 1 में पति या पत्नी के लिए, यदि आप एक मेज में 1 पति या पत्नी को दूसरे में रखते हैं (मैं एक में पुरुषों और दूसरे में महिलाओं को कहने वाला था। ओह अच्छी तरह से)

निशान, आप बस एक "जोड़े" तालिका कर सकते हैं जहां पंक्तियाँ हमेशा जोड़े में आती हैं। लेकिन अन्यथा मैं आपके साथ सहमत हूँ, अहम् ... शेख़ी। : पी

— जोहान्सह

हाँ, मैं मार्क से भी सहमत हूँ। :-) (मैं अपने बेवकूफ जवाब को अस्वीकार करने की अनुमति देता हूं?)

— पॉल डब्ल्यू होमर

हाँ, "विनम्रता" के मालिक यह साबित करते हैं कि आप कितने स्मार्ट हैं। असली कायर उनके गूंगे जवाब हटा देते हैं ... अच्छी बात है कि वे डॉक्टर नहीं हैं, मेडिकल रिकॉर्ड मिटा रहे हैं। वास्तव में, यह एक अच्छी बात है कि हम या तो नहीं हैं; रिबूट एक खराब चिकित्सा उपचार होगा।

2

मैंने हमेशा यह सोचा है कि दुनिया के सबसे चतुर व्यक्ति (जो भी इस समय हो सकते हैं) के पास अभी भी udder मूर्खता के क्षण हैं। यह एक मानव अभिशाप है :-) जबकि मेरे कंप्यूटर के पास बुद्धिमत्ता के क्षण हैं।

— पॉल डब्ल्यू होमर