EAV डेटा स्टोरेज मॉडल के लिए LINQ PHP की समानता

PHP में LINQ के बारे में एक पोस्ट देखने के बाद , मैंने तुरंत इस क्षेत्र में अपनी सर्वोत्तम प्रथाओं को साझा करने का निर्णय लिया।
मेरा कार्यान्वयन एक पूर्ण LINQ से दूर है, लेकिन इसमें तकनीक की सबसे अधिक ध्यान देने योग्य विशेषता है - एक विदेशी क्वेरी स्ट्रिंग की कमी।

क्यों?

मेरी गतिविधि, दोनों काम करने और बहुत नहीं, डेटाबेस से संबंधित है, जिसमें एक ईएवी डेटा स्टोरेज मॉडल है। इसका मतलब यह है कि संस्थाओं की संख्या में वृद्धि के साथ, तालिकाओं की संख्या में वृद्धि नहीं होती है। सभी जानकारी सिर्फ दो तालिकाओं में संग्रहीत है।

ईएवी मॉडल में डेटा टेबल
स्वाभाविक रूप से, ऐसी संरचना से "रिकॉर्ड" प्राप्त करने के लिए, एक क्वेरी लिखना आवश्यक है जो सामान्य डेटाबेस संरचना के साथ समान क्वेरी से पूरी तरह से विपरीत है।
उदाहरण के लिए:

SELECT field_1, field_2, field_3 FROM object 

और ईव में

 SELECT f1.value_bigint, f2.value_bigint, f3.value_bigint FROM objects ob, attributes_values f1, attributes_values f2, attributes_values f3 WHERE ob.ID_type="object" AND f1.ID_object = ob.ID_object AND f1.ID_attribute = 1 AND f2.ID_object = ob.ID_object AND f2.ID_attribute = 2 AND f3.ID_object = ob.ID_object AND f3.ID_attribute = 3 

जैसा कि वे कहते हैं - अंतर महसूस करते हैं।
स्थिति इस तथ्य से जटिल है कि कई वस्तुएं रिश्तों से जुड़ी होती हैं जो इसी तरह एक अनुरोध को बढ़ाती हैं।

क्वेरी जनरेटर

एक बिंदु पर, मैं खराब पठनीय नूडल्स लिखने से थक गया था, जिसमें 50% - 70% सहायक कोड था। फिर अपने आप एक अनुरोध उत्पन्न करने के लिए विचार आया। तो IQB - इरो क्वेरी बिल्डर का जन्म हुआ। इसकी अवधारणा से प्रेरित था कि कैसे Drupal में डेटाबेस के साथ बातचीत काम करती है।
IQB में उपरोक्त क्वेरी इस तरह दिखाई देगी:

 $q = new IQB(); $query = $q->from(array(new IQBObject('ob','object'), new IQBAttr('f1',1,INT), new IQBAttr('f2',2,INT), new IQBAttr('f3',3,INT) )) ->where('f1','with','ob')->where('f2','with','ob')->where('f3','with','ob') ->select('f1')->select('f2')->select('f3') ->build(); 

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

 $q->where('attr','with','object'); 

शर्त लगाओ

 attr.ID_object = object.ID_object 

ऐसी अभिव्यक्ति से

 $q->where('attr','=','object'); 

एक समान लेकिन पूरी तरह से अलग अभिव्यक्ति प्राप्त करें

 attr.value_bigint = object.ID_object 

और यदि ऑब्जेक्ट तालिका से () में घोषित नहीं किया गया था, तो यह बाहर हो जाएगा (यदि विशेषता डेटा प्रकार स्ट्रिंग में बदल गया है)

 attr.value_ntext = "object" 

शर्तों के अनुसार, आप स्ट्रिंग्स '=', '! =', '> =', '<=', '>', '<', 'लाइक' और 'विथ' का उपयोग कर सकते हैं - यह विशेषता किसी विशिष्ट ऑब्जेक्ट से संबंधित है।
चयन () विधि जनरेटर को बताती है कि किस तालिका मान को चयन में गिरना चाहिए। इसके अलावा, आप "SUM ($)" जैसी लाइन को तीसरे तर्क के साथ विधि में पास करके फ़ंक्शन में "रैप" कर सकते हैं, और फ़ंक्शन में डॉलर के लिए टेबल फ़ील्ड प्रतिस्थापित किया जाएगा। दूसरा तर्क चयन में क्षेत्र का उपनाम है।
GroupBy () और orderBy () विधियों के साथ मिलकर, यह औसत रीड अनुरोध बनाने के लिए पर्याप्त है।

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

 $q->from(array( new IQBObject('b','B'), new IQBAttr('parent',23,INT), new IQBAttr('child',24,INT) )) ->where('parent','=',123456) // ID_object   ->where('child','with','parent') ->where('child','=','b') 

एक साधारण "ए से बी सहायक ले" के लिए बहुत कुछ। वस्तुओं के बंधन को स्वचालित करने के लिए, IQB में एक लिंक्ड () विधि है।
विधि एक ID_object या एक ज्ञात वस्तु का एक उपनाम, बच्चे / माता-पिता का एक उपनाम और "U- ध्वज" स्वीकार करता है संकेत - बच्चे की वस्तुओं या मूल वस्तुओं की तलाश करें। इस प्रकार, उपरोक्त कोड इस तरह लिखा जा सकता है:

 $q->from(new IQBObject('b','B'))->linked(123456,'b');//     . 

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

निष्कर्ष

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