संबंधपरक डेटाबेस एक नेस्टेड प्रारूप में जानकारी वापस करने का समर्थन क्यों नहीं करते हैं?


46

मान लीजिए मैं एक ब्लॉग बना रहा हूं, जिसमें मुझे पोस्ट और टिप्पणियां चाहिए। इसलिए मैं दो तालिकाएँ बनाता हूं, एक 'पोस्ट' तालिका जिसमें एक स्वत: अंकन पूर्णांक 'आईडी' कॉलम और एक 'टिप्पणियां' तालिका है जिसमें एक विदेशी कुंजी 'पोस्ट_ड' है।

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

SELECT id, content, (SELECT * FROM comments WHERE post_id = 7) AS comments
FROM posts
WHERE id = 7

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

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

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

(अस्वीकरण: मैं ज्यादातर रेल और NoSQL डेटास्टोर्स का उपयोग करके वेबपेज लिखता हूं, लेकिन हाल ही में मैं पोस्टग्रेज की कोशिश कर रहा हूं, और मुझे वास्तव में यह बहुत पसंद है। मैं रिलेशनल डेटाबेस पर हमला करने का मतलब नहीं हूं, मैं सिर्फ हैरान हूं।)

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


1
सभी ऑर्म्स उस तरह से काम नहीं करते हैं। हाइबरनेट / nhibernate जुड़ने के लिए निर्दिष्ट करने की अनुमति देता है, और एक ही क्वेरी से पूरे ऑब्जेक्ट पेड़ों को उत्सुकता से लोड कर सकता है।
नाथन गोंजालेज

1
चर्चा का एक दिलचस्प बिंदु भी है, लेकिन मुझे यकीन नहीं है कि यह वास्तव में जवाबदेह है, एएनआई एसक्यूएल लोगों के साथ बैठक के बिना जवाबदेह है
नथन गोनज़ेलेज़

@ नथन: हाँ, सभी नहीं। मैं सीक्वल का उपयोग कर रहा हूं जो आपको यह चुनने देता है कि आप किसी दिए गए क्वेरी ( डॉक्स ) के लिए कौन सा दृष्टिकोण पसंद करते हैं , लेकिन वे अभी भी कई-क्वेरी दृष्टिकोण (प्रदर्शन कारणों के लिए, मुझे लगता है) को प्रोत्साहित करते हैं।

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

1
वे xml
इयान

जवाबों:


42

CJ Date, SQL 7 और परिशिष्ट सिद्धांत के अध्याय 7 और परिशिष्ट B में इसके बारे में विस्तार से बताया गया है । आप सही हैं, संबंधपरक सिद्धांत में ऐसा कुछ भी नहीं है जो किसी विशेषता के डेटा प्रकार को स्वयं एक संबंध होने से रोकता है, जब तक कि यह प्रत्येक पंक्ति पर समान संबंध प्रकार न हो। आपका उदाहरण योग्य होगा।

लेकिन तारीख कहती है कि इस तरह की संरचनाएं "आमतौर पर - लेकिन हमेशा नहीं - contraindicated" (यानी एक खराब विचार) हैं क्योंकि संबंधों की पदानुक्रम असममित हैं । उदाहरण के लिए, नेस्टेड संरचना से एक परिचित "फ्लैट" संरचना में परिवर्तन हमेशा घोंसले के शिकार को उलटने के लिए नहीं किया जा सकता है।

यदि आप संबंध-मूल्यवान विशेषताओं (RVA) की अनुमति देते हैं तो RDBMS का समर्थन करने के लिए क्वेरी, बाधाएं और अपडेट अधिक जटिल, लिखने में कठिन और कठिन हैं।

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

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

जो मैं समझता हूं (मैंने उनका उपयोग नहीं किया है), रिले और डाटफोर आरडीबीएमएस परियोजनाएं हैं जो संबंध-मूल्यवान विशेषताओं का समर्थन करती हैं।


@Dportas से पुनः टिप्पणी करें:

संरचित प्रकार SQL-99 का हिस्सा हैं, और Oracle इनका समर्थन करता है। लेकिन वे आधार तालिका की पंक्ति प्रति नेस्टेड तालिका में कई tuples संग्रहीत नहीं करते हैं। सामान्य उदाहरण एक "पता" विशेषता है जो आधार तालिका का एक एकल स्तंभ प्रतीत होता है, लेकिन आगे सड़क, शहर, डाक कोड, आदि के लिए उप-स्तंभ हैं।

नेस्टेड टेबल भी ओरेकल द्वारा समर्थित हैं, और ये बेस टेबल की प्रति पंक्ति में कई ट्यूपल की अनुमति देते हैं। लेकिन मुझे पता नहीं है कि यह मानक एसक्यूएल का हिस्सा है। औरएक ब्लॉगके निष्कर्ष कोध्यान में रखें: "मैं एक सृजन तालिका में किसी नेस्टेड टेबल का उपयोग कभी नहीं करूंगा। आप अपना सारा समय UN-NESTING में बिताकर उन्हें फिर से उपयोगी बनाने के लिए खर्च करें!"


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

परिणाम सेट और टेबल एक तरह के होते हैं। दिनांक उन्हें कॉल संबंधों और relvars (सादृश्य द्वारा, 42 एक पूर्णांक है, जबकि एक चर क्रमशः xपूर्णांक 42 का मूल्य हो सकता है)। एक ही संचालन संबंधों और संबंधों पर लागू होता है, इसलिए उनकी संरचना को संगत बनाने की आवश्यकता होती है।
बिल कारविन

2
मानक SQL नेस्टेड तालिकाओं का समर्थन करता है। उन्हें "संरचित प्रकार" कहा जाता है। Oracle एक DBMS है जिसमें यह सुविधा है।
nvogel

2
क्या यह तर्कहीन नहीं है कि डेटा डुप्लीकेशन से बचने के लिए, आपको अपनी क्वेरी को सपाट, डेटा-डुप्लिकेट तरीके से लिखना होगा?
ईमोन नेरबोन

1
@EamonNerbonne, रिलेशनल ऑपरेशन की समरूपता। उदाहरण के लिए, प्रक्षेपण। यदि मैं RVA से कुछ उप-विशेषताओं का चयन करता हूं, तो मैं मूल पदानुक्रम को पुन: उत्पन्न करने के लिए सेट किए गए परिणाम के खिलाफ एक रिवर्स ऑपरेशन कैसे लागू कर सकता हूं? मुझे दिनांक 293 की पृष्ठ संख्या Google पुस्तक पर मिली है, इसलिए आप देख सकते हैं कि उसने क्या लिखा है: books.google.com/…
बिल करविन

15

जल्द से जल्द डेटाबेस सिस्टम के कुछ पदानुक्रमित डेटाबेस मॉडल पर आधारित थे । यह एक पेड़ में माता-पिता और बच्चों के साथ संरचना की तरह डेटा का प्रतिनिधित्व करता है, जैसा कि आप यहाँ सुझा रहे हैं। HDMS मोटे तौर पर रिलेशनल मॉडल पर निर्मित डेटाबेस द्वारा अधिगृहीत किए गए थे। इसके प्रमुख कारण यह थे कि RDBMS "कई से कई" रिश्तों को मॉडल कर सकता था जो कि पदानुक्रमित डेटाबेस के लिए कठिन थे और RDBMS आसानी से ऐसे प्रश्न कर सकते थे जो मूल डिज़ाइन का हिस्सा नहीं थे जबकि HDBMS ने आपको डिज़ाइन समय पर निर्दिष्ट पथ के माध्यम से क्वेरी करने के लिए विवश किया था।

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

इस विषय का व्यापक कवरेज निम्नलिखित लेख में उपलब्ध है


10

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

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

मुझे 2 प्रश्न भेजने और परिणामों के 2 बैच प्राप्त करने में कुछ भी अक्षम नहीं दिखता है:

--- Query-1-posts
SELECT id, content 
FROM posts
WHERE id = 7


--- Query-2-comments
SELECT * 
FROM comments 
WHERE post_id = 7

मेरा तर्क है कि (लगभग) सबसे कुशल तरीका है (लगभग, जैसा कि आपको वास्तव में आवश्यकता posts.idनहीं है और सभी कॉलम से नहीं comments.*)

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

मैं वास्तव में ORM के बारे में नहीं बोल सकता, लेकिन शायद उनमें से कुछ हमारे लिए इस काम का हिस्सा बन सकते हैं।

वेब सर्वर और क्लाइंट के बीच डेटा के वितरण में इसी तरह की तकनीकों का उपयोग किया जा सकता है। अन्य तकनीकों (जैसे कैशिंग) का उपयोग किया जाता है ताकि डेटाबेस (या वेब या अन्य सर्वर) डुप्लिकेट अनुरोधों के साथ अतिभारित न हो।

मेरा अनुमान है कि मानक, जैसे कि एसक्यूएल, सबसे अच्छा है यदि वे एक क्षेत्र में विशेष बने रहें और किसी क्षेत्र के सभी क्षेत्रों को कवर करने का प्रयास न करें।

दूसरी ओर, SQL मानक सेट करने वाला कमेंट भविष्य में अन्यथा अच्छी तरह से सोच सकता है और इस तरह की अतिरिक्त सुविधा के लिए स्थिरीकरण प्रदान कर सकता है। लेकिन यह ऐसी चीज नहीं है जिसे एक रात में डिजाइन किया जा सकता है।


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

2
@ प्रशंसापूर्ण: कई प्रश्नों को चलाने के लिए किसी भी बढ़े हुए उपरि की आवश्यकता नहीं है। अधिकांश डेटाबेस आपको एक ही बैच में कई प्रश्न प्रस्तुत करने और एक क्वेरी से कई परिणाम सेट प्राप्त करने की अनुमति देते हैं।
डैनियल प्राइडेन

@PreciousBodilyFluids - ypercube के जवाब में SQL स्निपेट एक एकल क्वेरी है जो एक एकल डेटाबेस कॉल में भेजी जाएगी और एक प्रतिक्रिया में दो परिणाम सेट लौटाएगी।
कार्सन 63000

5

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


5

मुझे पता है कि जब आप XML के लिए उपयोग करते हैं तो कम से कम SQLServer नेस्टेड प्रश्नों का समर्थन करता है।

SELECT id, content, (SELECT * FROM comments WHERE post_id = posts.id FOR XML PATH('comments'), TYPE) AS comments
FROM posts
WHERE id = 7
FOR XML PATH('posts')

यहां समस्या RDBMS से समर्थन की कमी नहीं है, लेकिन तालिकाओं में नेस्टेड तालिकाओं के समर्थन की कमी है।

इसके अलावा, आपको आंतरिक जुड़ाव का उपयोग करने से क्या रोकता है?

SELECT id, content, comments.*
FROM posts inner join comments on comments.post_id = posts.id
WHERE id = 7

आप आंतरिक जुड़ाव को एक नेस्टेड तालिका के रूप में देख सकते हैं, केवल पहले 2 क्षेत्रों की सामग्री को दोहराया जा सकता है। मैं जुड़ने के प्रदर्शन के बारे में चिंता नहीं करूँगा, इस तरह से क्वेरी में एकमात्र धीमा हिस्सा डेटाबेस से क्लाइंट के लिए io है। यह केवल एक मुद्दा होगा जब सामग्री में बड़ी मात्रा में डेटा होता है। उस स्थिति में मैं दो प्रश्नों का सुझाव दूंगा, select id, contentएक आंतरिक जुड़ाव के साथ और दूसरा एक select posts.id, comments.*। यह मल्टीपल पोस्ट के साथ भी है, क्योंकि आप अभी भी केवल 2 प्रश्नों का उपयोग करेंगे।


प्रश्न इसे संबोधित करते हैं। या तो आपको दो गोल यात्राएं करनी हैं (इष्टतम नहीं) या आपको पहले दो कॉलम (यह भी इष्टतम नहीं) में अनावश्यक डेटा वापस करना होगा। वह इष्टतम समाधान चाहता है (मेरी राय में अवास्तविक नहीं)।
स्कॉट व्हिटलॉक

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

5

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

SELECT id, content, cursor(SELECT * FROM comments WHERE post_id = 7) AS comments
FROM posts
WHERE id = 7

1

कुछ नेस्टिंग (पदानुक्रमित) का समर्थन करते हैं।

यदि आप एक क्वेरी चाहते थे तो आपके पास एक तालिका हो सकती है जो स्वयं संदर्भ देती है। कुछ RDMS इस अवधारणा का समर्थन करते हैं। उदाहरण के लिए, SQL सर्वर के साथ एक पदानुक्रमित क्वेरी के लिए उपयोगकर्ता सामान्य टेबल एक्सप्रेशन (CTE) कर सकते हैं।

आपके मामले में पोस्ट स्तर 0 पर होंगे और तब सभी टिप्पणियां स्तर 1 पर होंगी।

अन्य विकल्प 2 प्रश्न हैं या दिए गए प्रत्येक रिकॉर्ड के लिए कुछ अतिरिक्त जानकारी के साथ जुड़ें (जो दूसरों ने उल्लेख किया है)।

पदानुक्रमित का उदाहरण:

https://stackoverflow.com/questions/14274942/sql-server-cte-and-recursion-example

उपरोक्त लिंक में, एम्पीवेल नेस्टिंग (या पदानुक्रम) के स्तर को दिखाता है।


मुझे SQL सर्वर में उप-परिणाम के बारे में कोई दस्तावेज़ नहीं मिल रहा है। CTE का उपयोग करते समय भी। परिणाम से मेरा मतलब है कि डेटा की पंक्तियाँ पर्याप्त रूप से टाइप किए गए स्तंभों के साथ पर्याप्त हैं। क्या आप अपने उत्तर के संदर्भ जोड़ सकते हैं?
SandRock

@ सैंडरॉक - एक डेटाबेस SQL ​​क्वेरी से वापस सेट किए गए एकल परिणाम को वापस भेज देगा। क्वेरी में ही स्तरों की पहचान करके आप एक पदानुक्रमित या नेस्टेड परिणाम सेट कर सकते हैं जिसे संसाधित किया जाना होगा। मुझे लगता है कि वर्तमान में हम निकटतम हैं कि हम डेटा को वापस लाने के लिए गोनिग हैं जो नेस्टेड है।
जॉन रेनोर

0

मुझे खेद है कि मुझे यकीन नहीं है कि मैं आपके मुद्दे को ठीक से समझ पा रहा हूं।

MSSQL में आप केवल 2 SQL स्टेटमेंट निष्पादित कर सकते हैं।

SELECT id, content
FROM posts
WHERE id = 7

SELECT * FROM comments WHERE post_id = 7

और यह एक साथ आपके 2 परिणाम सेट लौटाएगा।


प्रश्न पूछने वाला व्यक्ति कह रहा है कि यह कम कुशल है क्योंकि इसके परिणामस्वरूप डेटाबेस में दो राउंड-ट्रिप होती हैं, और हम आमतौर पर ओवरहेड के कारण राउंड ट्रिप को कम करने की कोशिश करते हैं। वह एक राउंड ट्रिप करना चाहता है और दोनों टेबल वापस लेना चाहता है।
स्कॉट व्हाइटलॉक

लेकिन यह एक दौर की यात्रा होगी। stackoverflow.com/questions/2336362/…
Biff MaGriff

0

RDBMs सिद्धांत पर आधारित हैं और वे सिद्धांत से चिपके रहते हैं। यह कुछ अच्छी स्थिरता, और गणितीय रूप से प्रमाणित विश्वसनीयता के लिए अनुमति देता है।

क्योंकि मॉडल सरल है और फिर से सिद्धांत के आधार पर लोगों के लिए अनुकूलन और कई कार्यान्वयन करना आसान बनाता है। यह NoSQL के विपरीत है जहां हर कोई इसे थोड़ा अलग करता है।

पिछले कुछ समय से पदानुक्रम डेटाबेस बनाने की कोशिश की जा रही है, लेकिन IIRC (इसे गूगल नहीं कर सकता है) के मुद्दे (चक्र और समानता दिमाग में आते हैं) थे।


0

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

कुछ चीजें डेटाबेस के रूप में अच्छी तरह से नहीं करते हैं, लेकिन यह उन्हें वैसे भी बनाने के लिए एक असंभव नहीं है। अन्य अनुप्रयोगों के लिए तैयार करना वर्तमान सिफारिश है, लेकिन यह उचित नहीं है कि ऐसा क्यों नहीं किया जा सकता है।

आपके सुझाव के खिलाफ मेरे पास एकमात्र तर्क "sql" तरीके से सेट इस परिणाम को संभालने में सक्षम है। यह डेटाबेस में एक परिणाम बनाने के लिए एक बुरा विचार है कि इसके साथ काम करने में सक्षम नहीं होगा या इसे कुछ हद तक हेरफेर कर सकता है। मान लीजिए कि मैंने आपके द्वारा सुझाए गए तरीके से एक दृश्य बनाया है, मैं इसे दूसरे चुनिंदा कथन में कैसे शामिल करूं? डेटाबेस परिणाम लेना और उनके साथ काम करना पसंद करते हैं। मैं इसे दूसरी तालिका में कैसे शामिल करूंगा? मैं आपके परिणाम की तुलना दूसरे से कैसे करूँगा?

फिर RDMS का लाभ sql का लचीलापन है। तालिका से डेटा का चयन करने के लिए सिंटैक्स सिस्टम में उपयोगकर्ताओं या अन्य वस्तुओं की सूची के बहुत करीब है (कम से कम यह लक्ष्य है।)। निश्चित रूप से कुछ अलग करने का कोई मतलब नहीं है। वे प्रक्रियात्मक कोड / कर्सर या डेटा के BLOBS को बहुत कुशलता से हैंडल करने के बिंदु पर भी उन्हें प्राप्त नहीं करते हैं।


0

मेरी राय में यह ज्यादातर SQL की वजह से है और जिस तरह से एग्रीगेट क्वैश्चंस किए जाते हैं - परिणाम वापस करने के लिए एग्रीगेट फंक्शंस और ग्रुपिंग को बड़े 2-डायमेंशनल रोसेट पर निष्पादित किया जाता है। यह शुरुआत से ही ऐसा है और यह बहुत तेज़ है (अधिकांश NoSQL समाधान एकत्रीकरण के साथ काफी धीमा हैं और जटिल प्रश्नों के बजाय असामान्य स्कीमा पर भरोसा करते हैं)

बेशक PostgreSQL में ऑब्जेक्ट-ओरिएंटेड डेटाबेस से कुछ विशेषताएं हैं। इस मेल ( संदेश ) के अनुसार आप कस्टम एग्रीगेट बनाकर जो चाहें हासिल कर सकते हैं।

व्यक्तिगत रूप से मैं Doctrine ORM (PHP) जैसे फ्रेमवर्क का उपयोग कर रहा हूं जो प्रदर्शन बढ़ाने के लिए एकत्रीकरण एप्लिकेशन-साइड और सपोर्ट फीचर्स जैसे आलसी-लोडिंग करते हैं।


0

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


1
ऐसा लगता नहीं है कि बनाए गए अंकों से अधिक कुछ भी प्रस्तुत नहीं किया गया है और पहले 13 उत्तरों में समझाया गया है
gnat

इस प्रश्न में विशेष रूप से JSON का उल्लेख है और यह उत्तर केवल यह इंगित करने के लिए है कि JSON को कम से कम एक RDBMS से प्रश्नों में वापस किया जा सकता है। मैंने यह कहने के लिए सवाल पर टिप्पणी की होगी कि यह एक झूठे आधार पर आधारित है और इसलिए कोई निश्चित जवाब की उम्मीद नहीं कर सकता है। हालाँकि, StackExchange मुझे ऐसा नहीं करने देगा।
जोनाथन रोजर्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.