हमारी कंपनी उन रिपोर्टों से प्यार करती है जो अस्पष्ट मेट्रिक्स की गणना करते हैं - मेट्रिक्स जिन्हें ActiveRecord के खोजकर्ताओं (find_by_sql को छोड़कर) के साथ गणना नहीं की जा सकती है और जहां ruport की रूबी-आधारित क्षमताओं को बहुत धीमा कर दिया जाता है।कम्प्यूटेशनल-भारी प्रश्नों के लिए find_by_sql के विकल्प क्या हैं?
क्या वहां कोई प्लगइन या मणि या डीबी एडाप्टर है जो डेटाबेस परत में बड़ी गणना करेगा? जटिल रिपोर्ट बनाने का आपका क्या समाधान है?
यदि आप पाते हैं कि ActiveRecord में जटिल क्वेरी के लिए आवश्यक अभिव्यक्ति की कमी है तो आप अपने ORM के लिए DataMapper या Sequel का उपयोग करना चाहेंगे। ActiveRecord से दूर स्विचिंग संभवतः लेने का निर्णय नहीं होगा, लेकिन कम से कम जांच करना उचित हो सकता है।
यद्यपि अभी यह हमारी परियोजना में ऐसा करने में बहुत देर हो चुकी है, मुझे विश्वास है कि यह हमारी पसंद आगे बढ़ेगा। मैंने डेटामैपर में बहुत कुछ नहीं देखा है, लेकिन इसके बारे में कई महान कहानियां सुनाई हैं। धन्यवाद पीट! – btelles
Thoughtbot की गिलहरी प्लगइन, बहुस्तरीय सशर्त, साथ, ActiveRecord की ढूंढें विधि के लिए रूबी-ish कार्यक्षमता का एक बहुत कहते हैं पर्वतमाला, और नेस्टेड मॉडल संघों:
www.thoughtbot.com/projects/squirrel/
उत्कृष्ट विचार! हमने 'जहां' कथन को अधिक प्रभावी ढंग से उत्पन्न करने के लिए सर्चलॉगिक और गिलहरी को देखा है, लेकिन एक समस्या में कई फ़ील्ड के बीच मूल्यों की गणना के साथ हम जिस समस्या का सामना कर रहे हैं ... मुझे यकीन नहीं है कि इससे इस विशेष उपयोग में मदद मिलेगी मामला। लेकिन अगर वे करते हैं तो मुझे बताएं! – btelles
क्या आपकी रिपोर्ट के बारे में कुछ भी निहित है जो SQL दृश्य या संग्रहीत प्रक्रिया के उपयोग को रोकता है?
एक विशेष परियोजना में, एक तकनीक है मैं अक्सर उपयोगी पाते डेटाबेस में एक नामित दृश्य के रूप में अपने SQL क्वेरी (कि काफी जटिल हो सकता है) बनाने के लिए, और फिर
YourModel.connection.select_all(query)
का उपयोग वापस खींचने के लिए है डेटा। यह एक इष्टतम दृष्टिकोण नहीं है; मैं इसमें सुधार का पता लगाने के लिए उत्सुक हूं।
दुर्भाग्य से, जैसा कि आपने सुझाव दिया है, रेलिंग के भीतर जटिल डेटाबेस-आधारित रिपोर्ट कंप्यूटिंग करने के लिए समर्थन काफी सीमित लगता है।
हां, हमारी दुकान में एक एसक्यूएल गुरु है जो वास्तव में उस विकल्प को पसंद करेगा। और यह एक व्यावहारिक दृष्टिकोण की तरह लगता है ... मुझे इसके साथ कोई समस्या नहीं है, एक को बचाओ ... डीबी अज्ञेयवाद को बनाए रखना थोड़ा मुश्किल है जब मैं माइग्रेशन बनाता हूं जिसमें डेटाबेस प्रकार के लिए विशिष्ट संग्रहित प्रक्रियाएं शामिल होती हैं। विचार निश्चित रूप से पकड़ने के लिए निश्चित हैं! इनपुट के लिए धन्यवाद, और देर से प्रतिक्रिया के लिए खेद है! – btelles
हालांकि डेटाबेस अज्ञेयवादी नहीं है, हमारा समाधान plpgsql फ़ंक्शन है जहां यह रूबी और ActiveRecord का उपयोग करने में वास्तव में धीमा हो जाता है।
हाँ, हम वास्तव में कुछ ऐसा करने की कोशिश कर रहे हैं जो डीबी अज्ञेयवादी है। हालांकि इनपुट के लिए धन्यवाद! – btelles
ऐसा लगता है जैसे आपकी टेबल सामान्यीकृत की जा सकती है। एक स्थान पर मैंने काम किया, हमारे द्वारा किए गए सामान्यीकरण की मात्रा हमारी रिपोर्टिंग आवश्यकताओं को प्रभावित कर रही थी, इसलिए हमने कुछ छाया तालिकाएं बनाईं जिनमें कुल डेटा का एक समूह था, और इसके खिलाफ रिपोर्टिंग की।
मैं नील एन की टिप्पणी से सहमत हूं कि सवाल थोड़ा अस्पष्ट है, लेकिन शायद यह आपको सही दिशा में आगे बढ़ता है?
हां, सवाल निश्चित रूप से अस्पष्ट है। लेकिन डेटा सामान्यीकरण थोड़ा अलग समस्या हल करेगा, और हमारे डेटा को सामान्य करने से वास्तव में कुछ और प्रश्नों को धीमा कर दिया जाएगा। हालांकि योगदान करने के लिए धन्यवाद! – btelles
मेरा मतलब था, रिपोर्टिंग उद्देश्यों के लिए सामान्यीकरण पर विचार करें। –
मुझे लगता है कि बहुत से लोग इस प्रश्न को देख रहे हैं, लेकिन कोई भी काटने का काम नहीं कर रहा है। क्या लोगों को स्टैब या दो लेने से मना कर दिया गया है? – btelles
मुझे लगता है कि आपका प्रश्न बहुत अस्पष्ट है .. अवधारणा बहुत मजेदार लगती है .. लेकिन आपके विशिष्ट परिदृश्य को पर्याप्त रूप से वर्णित नहीं किया जा सकता है। –
मेरी राय में आपकी रिपोर्ट प्राप्त करने के लिए SQL का उपयोग करके कुछ भी गलत है। 80-20 प्रतिशत नियम याद रखें: ActiveRecord आपके सीआरयूडी समस्या को हल करना आसान बनाता है, अन्य 20 प्रतिशत आपके ऊपर है। साथ ही, मेरे अनुभव रिपोर्ट में आपके द्वारा उपयोग किए जाने वाले मॉडल के साथ कुछ भी करने की ज़रूरत नहीं है। – Igor