लोड की गई परियोजनाओं में प्रभावी Django-ORM अनुरोधों के निर्माण के लिए नोट्स

इसके बाद से लिखा है हाई-लोड प्रोजेक्ट (HL) में SQL बनाम ORM पर टिप्पणियों में एक और होलीवर दिखाई दिया

प्रस्तावना

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

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

और-और-और, लेख ORM को समझने में त्रुटियां दिखाएगा कि मुझे Django के साथ काम करने के तीन से अधिक वर्षों में सामना करना पड़ा।

ओआरएम को नहीं समझा

मैं एक क्लासिक गलती से शुरू करूँगा जिसने मुझे काफी समय तक परेशान किया। उरुग्वे बंदरों की जनजाति में मान्यताओं के बारे में। मैं दृढ़ता से Django ORM की सर्वव्यापीता में विश्वास करता था, अर्थात्

Klass.objects.all() 

उदाहरण के लिए:

 all_result = Klass.objects.all() result_one = all_result.filter(condition_field=1) result_two = all_result.filter(condition_field=2) 

मेरे सपनों में, सोच इस प्रकार थी:

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

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

• गणना करते समय पहली पंक्ति, एनालॉग है
  

   select * from table; 

  
  
• गणना करते समय दूसरी पंक्ति, एनालॉग है
  

   select * from table where condition_field=1; 

  
  
• गणना में तीसरी पंक्ति, एनालॉग है
  

   select * from table where condition_field=2; 

  
  

हुर्रे! हमने साबित किया है कि हमारे पास तीन अनुरोध हैं। लेकिन मुख्य वाक्यांश "गणना में" है। वास्तव में, हम दूसरे भाग पर जाते हैं - यह प्रमाण कि हमारे पास केवल दो अनुरोध हैं।
इस समस्या के लिए, ORM की निम्न समझ (2 वाक्यों में) हमारी मदद करेगी:

• अब तक हमने कुछ भी गणना नहीं की है - हम केवल ओआरएम टूल का उपयोग करके एक अनुरोध बनाते हैं। जैसे ही हमने गणना करना शुरू किया, हम प्राप्त उत्पन्न अनुरोध द्वारा गणना करते हैं।
  

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

 for result in result_one: print result.id 

हमेशा आवश्यक कार्य और उचित चयन नहीं

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

 class RegionSite(models.Model): name = models.CharField(verbose_name="", max_length=200,) def __unicode__(self): return "%s" % self.name class News(models.Model): region = models.ForeignKey(RegionSite, verbose_name="") date = models.DateField(verbose_name="", blank=True, null=True, ) name = models.CharField(verbose_name="", max_length=255) def __unicode__(self): return "%s (%s)" % (self.name, self.region) 

हमें 10 नवीनतम समाचारों को प्रिंट करने की आवश्यकता है, जैसा कि समाचार में परिभाषित नाम के साथ है। यूनिकोड __ ()
आस्तीन को उजागर करें, और लिखें:

 news = News.objects.all().order_by("-date")[:10] 

टेम्पलेट में:

 {% for n in news %} {{ n }} {% endfor %} 

और यहां हमने अपने लिए एक छेद खोदा। यदि यह समाचार नहीं है, या उनमें से 10 नहीं हैं - लेकिन 10 हजार हैं, तो इस तथ्य के लिए तैयार रहें कि आपको 10,000 अनुरोध प्राप्त होंगे + 1. और विदेशी कीचड़ के कारण सभी।
एक अतिरिक्त 10 हजार प्रश्नों का एक उदाहरण (और कहते हैं कि एक छोटा मॉडल होने के लिए धन्यवाद - सभी फ़ील्ड और मॉडल मान इस तरह चुने जाएंगे, चाहे वह 10 या 50 फ़ील्ड हों):

 SELECT `seo_regionsite`.`id`, `seo_regionsite`.`name` FROM `seo_regionsite` WHERE `seo_regionsite`.`id` = 1 SELECT `seo_regionsite`.`id`, `seo_regionsite`.`name` FROM `seo_regionsite` WHERE `seo_regionsite`.`id` = 1 SELECT `seo_regionsite`.`id`, `seo_regionsite`.`name` FROM `seo_regionsite` WHERE `seo_regionsite`.`id` = 2 SELECT `seo_regionsite`.`id`, `seo_regionsite`.`name` FROM `seo_regionsite` WHERE `seo_regionsite`.`id` = 1 --  

ऐसा क्यों हो रहा है? जननांगों के लिए सब कुछ सरल है। हर बार जब आप समाचार का नाम प्राप्त करते हैं, तो हमारा निवेदन है कि समाचार के क्षेत्र का नाम प्रदर्शित करने के लिए उसका __ यूनिकोड __ () मान लौटाएं , और कोष्ठक में स्थानापन्न करें।
इसी तरह, एक खराब स्थिति तब शुरू होती है जब हम, उदाहरण के लिए, ORM का उपयोग करने वाले टेम्पलेट में, उदाहरण के लिए, हमारे लिए आवश्यक मूल्य प्राप्त करने का प्रयास करते हैं:

 {{ subgroup.group.megagroup.name }} 

आपको विश्वास नहीं होगा कि क्या कोई कठिन अनुरोध हो सकता है :) मैं यह नहीं कह रहा हूँ कि आपके पास ऐसे दर्जनों नमूने हो सकते हैं!
आपने अभी हमें इतना नहीं लिया है - हमने सोब किया और ORM के अगले महान अवसर का लाभ उठाया -। ()
मैजिक-कीबोर्ड तरीके से कोड की हमारी लाइन में बदल जाती है:

 news = News.objects.all().values("name", "region__name").order_by("-date")[:10] 

एक टेम्प्लेट:

 {% for n in news %} {{ n.name }} ({{ n.region__name }}) {% endfor %} 

डबल अंडरस्कोर नोट करें। यह जल्द ही हमारे लिए उपयोगी होगा। (जो लोग जानते नहीं हैं - डबल अंडरलाइनिंग, जैसा कि यह था, मॉडल के बीच संबंध, इसे स्पष्ट रूप से डालने के लिए)
इन सरल जोड़तोड़ से हमें 10 हजार अनुरोधों से छुटकारा मिला और केवल एक ही बचा। वैसे, हाँ, यह जॉइन के साथ और हमारे द्वारा चुने गए क्षेत्रों के साथ काम करेगा!

 SELECT `news_news`.`name`, `seo_regionsite`.`name` FROM `news_news` INNER JOIN `seo_regionsite` ON (`news_news`.`region_id` = `seo_regionsite`.`id`) LIMIT 10 

हम पागलों की तरह खुश हैं! आखिरकार, हम सिर्फ ORM ऑप्टिमाइज़र बन गए हैं :) कुछ वहाँ! मैं आपको बताता हूँ :) यह अनुकूलन अनुकूलन है जब तक कि हमारे पास 10 हजार समाचार नहीं हैं। लेकिन हम इसे और भी तेजी से कर सकते हैं!
ऐसा करने के लिए, अनुरोधों की संख्या के संदर्भ में हमारे पूर्वाग्रहों को ध्यान में रखें और अनुरोधों की संख्या में 2 गुना वृद्धि करें! अर्थात्, हम डेटा तैयार करेंगे:

 regions = RegionSite.objects.all().values("id", "name") region_info = {} for region in regions: region_info[region["id"]] = region["name"] news = News.objects.all().values("name", "region_id").order_by("-date")[:10] for n in news: n["name"] = "%s (%s)" % (n["name"], region_info[n["region_id"]]) 

और फिर हमारे ताज़ा सेट चर के टेम्पलेट में आउटपुट:

 {% for n in news %} {{ n.name }} {% endfor %} 

हां, मैं समझता हूं ... इन पंक्तियों के साथ हमने एमवीटी की अवधारणा का उल्लंघन किया। लेकिन यह केवल एक उदाहरण है जिसे आसानी से उन लाइनों में परिवर्तित किया जा सकता है जो एमवीटी मानकों का उल्लंघन नहीं करते हैं।
हमने क्या किया है?

1. हमने क्षेत्रों पर डेटा तैयार किया और शब्दकोश में उनके बारे में जानकारी दर्ज की:
   

    SELECT `seo_regionsite`.`id`, `seo_regionsite`.`name` FROM `seo_regionsite` 

   
   
2. समाचार से वह सब कुछ चुना जाता है जो हमें रुचिकर करता है + एक ही रेखांकन पर ध्यान देता है।
   

    SELECT `news_news`.`name`, `news_news`.`region_id` FROM `news_news` LIMIT 10 

   
   यह एकल अंडरस्कोर के साथ था जिसे हमने डेटाबेस में लिंक का सीधा अर्थ चुना।
3. हमने दो मॉडलों को अजगर के साथ जोड़ा।

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

 item.group_id vs. item.group.id 

न केवल प्रश्नों का निर्माण करते समय, बल्कि परिणामों को संसाधित करते समय, आप इस सुविधा में भाग सकते हैं।
एक उदाहरण:

 for n in News.objects.all(): print n.region_id 

समाचार का चयन करते समय केवल एक ही अनुरोध होगा -
उदाहरण 2:

 for n in News.objects.all(): print n.region.id 

10 हजार अनुरोध + 1 होंगे, क्योंकि प्रत्येक पुनरावृत्ति में हमारे पास आईडी के लिए हमारा अनुरोध होगा। यह समान होगा:

 SELECT `seo_regionsite`.`id`, `seo_regionsite`.`name` FROM `seo_regionsite` WHERE `seo_regionsite`.`id` = 1 

यहाँ एक संकेत के कारण ऐसा अंतर है।
कई उन्नत dzhangovody अब मेरे कोड के साथ वूडू गुड़िया पर एक उंगली प्रहार करते हैं। और उसी समय वे मुझसे एक सवाल पूछते हैं - आप डेटा की तैयारी के साथ बर्फ़ीला तूफ़ान के लिए क्या कर रहे हैं, और कहाँ हैं values_list ("आईडी", फ्लैट = सच) ?
आइए एक अद्भुत उदाहरण देखें , जो value_list के साथ काम करने में सटीकता की आवश्यकता को दर्शाता है :

 regions_id = RegionSite.objects.filter(id__lte=10).values_list("id", flat=True) for n in News.objects.filter(region__id__in=regions_id): print n.region_id 

कोड की इन पंक्तियों के साथ, हम:

1. हम कुछ अमूर्त स्थिति द्वारा हमारे लिए ब्याज के क्षेत्रों के आईडी-शिकोन्स की एक सूची तैयार कर रहे हैं।
2. परिणामी परिणाम हमारी समाचार क्वेरी में डाला जाता है और हमें प्राप्त होता है:
   

    SELECT `news_news`.`id`, `news_news`.`region_id`, `news_news`.`date`, `news_news`.`name` FROM `news_news` WHERE `news_news`.`region_id` IN (SELECT U0.`id` FROM `seo_regionsite` U0 WHERE U0.`id` <= 10 ) 

निवेदन में निवेदन! Uuuuh, मुझे पसंद है :) विशेष रूप से IN (10 हजार ID) के साथ एम्बेडेड चयन के साथ 10 हजार समाचार चुनें
क्या आप निश्चित रूप से समझते हैं कि इससे क्या खतरा है? :) अगर नहीं - तो समझ लो - कुछ नहीं, बिल्कुल कुछ भी अच्छा नहीं!
इस मुद्दे का हल भी सरल है। हमारे लेख की शुरुआत को याद करें - चर का मूल्यांकन किए बिना कोई भी क्वेरी प्रकट नहीं होती है। और एक टिप्पणी करें, उदाहरण के लिए, कोड की दूसरी पंक्ति पर:

 for n in News.objects.filter(region__id__in=list(regions_id)): 

और इस समाधान के साथ हमें 2 सरल प्रश्न मिलते हैं। कोई अटैचमेंट नहीं।
आपने अभी भी हमारे लिए स्टोर में कमीने ORM से अपनी सांस नहीं ली है? फिर हम और भी गहरे हो जाएंगे। कोड पर विचार करें:

 regions_id = list(News.objects.all().values_list("region_id", flat=True)) print RegionSite.objects.filter(id__in=regions_id) 

इन दो पंक्तियों के साथ, हम उन क्षेत्रों की सूची का चयन करते हैं जिनके लिए हमारे पास समाचार हैं। इस कोड में सब कुछ महान है, एक बिंदु को छोड़कर, अर्थात् परिणामी अनुरोध:

 SELECT `seo_regionsite`.`id`, `seo_regionsite`.`name` FROM `seo_regionsite` WHERE `seo_regionsite`.`id` IN (1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9) LIMIT 21 

अहा, ORM, इसे रोको! क्या कर रहे हो!
इतना ही नहीं, सभी समाचारों से (मेरे उदाहरण में यह 256 है, ऐसा लगता है), उन्होंने क्षेत्रों की आईडी का चयन किया और बस उन्हें प्रतिस्थापित किया, इसलिए उन्होंने कहीं से 21 की सीमा ले ली। सब कुछ सीमा के बारे में सरल है - यह है कि बड़ी संख्या में सरणी मानों का प्रिंट कैसे काम करता है (I मुझे एक और बहाना नहीं मिला), लेकिन यहाँ उन मूल्यों के साथ स्पष्ट रूप से एक घात है।
समाधान, पिछले उदाहरण में, सरल है:

 print RegionSite.objects.filter(id__in=set(regions_id)).values("id", "name") 

सेट के माध्यम से अतिरिक्त तत्वों को हटाने के बाद , हमें अपेक्षित रूप से एक पर्याप्त अनुरोध प्राप्त हुआ:

 SELECT `seo_regionsite`.`id`, `seo_regionsite`.`name` FROM `seo_regionsite` WHERE `seo_regionsite`.`id` IN (1, 2, 3, 4, 9) LIMIT 21 

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

 region = RegionSite.objects.get(id=1) t = datetime.datetime.now() for i in range(1000): list(News.objects.filter(region__in=[region]).values("id")[:10]) # list(News.objects.filter(region__id__in=[region.id]).values("id")[:10]) # list(News.objects.filter(region__in=[1]).values("id")[:10]) # list(News.objects.filter(region__id__in=[1]).values("id")[:10]) print datetime.datetime.now() - t 

प्रत्येक पुनरावृति लाइनों को क्रमिक रूप से शामिल किया गया था (ताकि केवल एक ही काम किया जाए)। कुल हम निम्नलिखित संख्या प्राप्त कर सकते हैं:

• 1 पंक्ति - 6.362800 सेकंड
• दूसरी पंक्ति - 6.073090 सेकंड
• तीसरी पंक्ति - 6.431563 सेकंड
• 4 वीं पंक्ति - 6.126252 सेकंड

विसंगतियां न्यूनतम हैं, लेकिन दृश्यमान हैं। पसंदीदा 2 और 4 विकल्प (मैं मुख्य रूप से 4 मी का उपयोग करता हूं)। समय की मुख्य बर्बादी कितनी जल्दी हम एक अनुरोध बनाते हैं। तुच्छ, लेकिन महत्वपूर्ण, मुझे लगता है। प्रत्येक पाठक स्वतंत्र रूप से निष्कर्ष निकालेगा।
और हम लेख को एक डरावने शब्द - लेनदेन के साथ समाप्त करते हैं।
विशेष मामला:

• आपके पास InnoDB है
• आपको तालिका में डेटा को अपडेट करने की आवश्यकता है, जिसमें ग्राहक लिखते नहीं हैं, लेकिन केवल पढ़ते हैं (उदाहरण के लिए, सामानों की सूची)

एक-दो अद्यतन / सम्मिलन किया जाता है

1. हम डेटा डालने और डेटा अपडेट करने के लिए 2 डिक्शनरी तैयार करते हैं
2. प्रत्येक शब्दकोश हम उसके कार्य में फेंक देते हैं
3. लाभ!

वास्तविक अपडेट फ़ंक्शन का एक उदाहरण:

 @transaction.commit_manually def update_region_price(item_prices): """     """ from idea.catalog.models import CatalogItemInfo try: for ip in item_prices: CatalogItemInfo.objects.filter( item__id=ip["item_id"], region__id=ip["region_id"] ).update( kost=ip["kost"], price=ip["price"], excharge=ip["excharge"], zakup_price=ip["zakup_price"], real_zakup_price=ip["real_zakup_price"], vendor=ip["vendor"], srok=ip["srok"], bonus=ip["bonus"], rate=ip["rate"], liquidity_factor=ip["liquidity_factor"], fixed=ip["fixed"], ) except Exception, e: print e transaction.rollback() return False else: transaction.commit() return True 

वास्तविक ऐड फंक्शन का एक उदाहरण:

 @transaction.commit_manually def insert_region_price(item_prices): """     """ from idea.catalog.models import CatalogItemInfo try: for ip in item_prices: CatalogItemInfo.objects.create(**ip) except Exception, e: print e transaction.rollback() return False else: transaction.commit() return True 

इन बिंदुओं को जानते हुए, आप Django ORM का उपयोग करके प्रभावी एप्लिकेशन बना सकते हैं, और SQL कोड में फिट नहीं हो सकते।

सवालों के जवाब:

चूंकि ऐसा नृत्य चला गया है, तब लिखें जब यह ओआरएम का उपयोग करने लायक हो, और जब नहीं। (c) लवो
मुझे लगता है कि ओआरएम को हमेशा सरल होने पर उपयोग करना चाहिए। ORM को अपने कंधों पर न रखें, और इससे भी अधिक आधार प्रश्न जैसे:

 User.objects.values('username', 'email').annotate(cnt=Count('id')).filter(cnt__gt=1).order_by('-cnt') 

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

मुझे आश्चर्य है कि Django क्यों। अन्य ढांचे / प्रौद्योगिकियों की तुलना में इस ढांचे (और इसके ओआरएम) के क्या लाभ हैं। (c) अंजेंसन
ऐतिहासिक दृष्टि से। अजगर ने Django के साथ अध्ययन करना शुरू किया। और मैं इसके उपयोग की तकनीक में अधिकतम तक ज्ञान लाता हूं। अब पिरामिड के समानांतर अध्ययन में। मैं अब तक केवल PHP और उनके फ्रेमवर्क, सेमी के साथ तुलना कर सकता हूं। मैं शायद एक सामान्य वाक्यांश कहूंगा - जब मैंने PHP में लिखा था तो मैंने अपना समय अप्रभावी रूप से बर्बाद कर दिया था ।
अब मैं Django 1.3.4 में कुछ गंभीर खामियों का नाम दे सकता हूं:

1. आधार के साथ स्थायी संबंध / वियोग (पुराने संस्करणों में सही)
2. टेम्पलेट प्रोसेसर की गति। नेटवर्क पर पाए गए परीक्षणों के अनुसार, यह काफी छोटा है। बदलने की जरूरत है :)

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

किस प्रकार का प्रोग्रामर है जो SQL क्वेरी लिखना मुश्किल है? (c) andreynikishaev
एक प्रोग्रामर जो प्रोग्राम कोड पर अपने समय को महत्व देता है, और बेस-कोड डेटा प्रोसेसिंग के बीच बातचीत के साधन पर नहीं। आपको SQL जानने की जरूरत है - बहुत बार मैं डेटाबेस कंसोल के साथ सीधे काम करता हूं। लेकिन कोड में - ORM। ओआरएम बदलने या पूरक करने के लिए आसान और तेज़ है। और भी, यदि आप यथोचित आसान अनुरोध लिखते हैं, तो पढ़ना और समझना आसान है।

क्षमा करें, सब लोग! (ब्ला ब्ला ... टिप्पणियों, सुझावों, प्रश्नों, सुझावों की प्रतीक्षा)