क्या होगा अगर कोई SQL कथन एक डेटाबेस वापस लौटाए?
एक नया SQL extension यह प्रस्तावित करता है कि कोई query एक single denormalized result table के बजाय संबंधित tables का पूरा set—यानी एक छोटा, normalized “sub-database”—वापस लौटा सके। समर्थक ORMs, hierarchical data, performance (wire पर कम duplicated data), और schema/key information को बनाए रखने के लिए इसे उपयोगी मानते हैं, और इसे GraphQL, Datomic, तथा category-theoretic databases जैसी ideas से जोड़ते हैं। आलोचक कहते हैं कि मौजूदा tools (joins, multiple queries, JSON/JSONB, stored procedures) पहले से ही अधिकतर use cases कवर करते हैं और “database” बनाम “schema” जैसी शब्दावली में complexity जोड़ने से नया language feature उचित नहीं ठहरता।
अवधारणा: “SELECT RESULTDB” / डेटाबेस-जैसा परिणाम वापस करना
- प्रस्ताव: SQL को इस तरह बढ़ाया जाए कि कोई क्वेरी एक अकेले denormalized result set के बजाय कई संबंधित तालिकाएँ (डेटाबेस का एक “subset”) वापस लौटा सके।
- इसे एक “normalized join” की तरह समझें: आपको शामिल हर तालिका के लिए अलग-अलग relations मिलते हैं, केवल प्रासंगिक rows के साथ, और keys/relationships सुरक्षित रहते हैं।
- उद्देश्य joins में data duplication कम करना और परिणाम में अधिक schema/key जानकारी बनाए रखना है।
प्रेरणाएँ और उपयोग-केस
- प्रदर्शन: बड़े join परिणामों में parent data को बार-बार दोहराने से बचना; wire पर कम डेटा, खासकर parent–child/snowflake schemas में।
- ORMs: object graphs (जैसे recipes और ingredients, orders और customers) को N+1 queries या बड़े denormalized joins के बिना hydrate करना आसान हो।
- latency: कई queries की बजाय संबंधित relations को fetch करने के लिए एक round trip।
- consistency: एक ही query संबंधित data का snapshot दे सकती है, जिसे कई queries असंगत रूप से fetch कर सकती हैं।
- edge databases / local mirrors के लिए संभावित उपयुक्तता: offline या client-side querying के लिए एक “partial database” fetch करना।
आलोचनाएँ और संदेह
- कई लोगों का तर्क है कि मौजूदा tools पर्याप्त हैं: multiple queries (संभवतः parallel में), JSON/array aggregates, multiple result sets लौटाने वाले views, stored procedures, cursors।
- कुछ लोग denormalized query results को एक feature मानते हैं: queries का काम data को वांछित format में shape करना है, schema का mirror बनना नहीं।
- चिंता यह है कि memory में एक “result database” बनाना complexity को बस client की तरफ़ खिसका देता है, जिसे फिर उस पर दोबारा query करनी पड़ती है।
- कुछ लोगों को लगता है कि paper relational model को गलत समझता या गलत प्रस्तुत करता है, या “relational” को SQL की सीमाओं के साथ मिला देता है।
- अन्य इसे कई relations को pack/unpack करने के syntax sugar के रूप में देखते हैं।
संबंधित तकनीकें और पूर्व कार्य
- GraphQL, JSON:API, SQL JSON/JSONB support, SQL Server का
FOR JSON, ODBC/MARS multi-result sets, Akiban का “nested result set” जैसी चीज़ों से तुलना। - category-theoretic “queries as morphisms between databases” और graph/Datalog systems तथा Datomic-जैसी “database as value” अवधारणाओं से भी संबंध।
खुले प्रश्न और अस्पष्टताएँ
- keys, foreign keys, और aggregates (जैसे SUM, MAX) की सटीक semantics पर thread में चर्चा हुई है, लेकिन पूरी तरह तय नहीं हुई हैं।
- compression और मौजूदा patterns की तुलना में वास्तविक लाभ कितना है, इस पर बहस जारी है और यह स्पष्ट नहीं है।