मैं प्रत्येक प्रणाली की ताकत के लिए खेलूंगा।
तर्क को एकत्र करना, जोड़ना और फ़िल्टर करना स्पष्ट रूप से डेटा स्तर पर है। यह तेज़ है, न केवल इसलिए कि अधिकांश डीबी इंजनों के पास ऐसा करने के लिए 10+ साल का अनुकूलन है, बल्कि आप अपने डीबी और वेब सर्वर के बीच स्थानांतरित डेटा को कम करते हैं।
दूसरी ओर, मेरे द्वारा उपयोग किए गए अधिकांश डीबी प्लेटफार्मों में व्यक्तिगत मूल्यों के साथ काम करने के लिए बहुत खराब कार्यक्षमता है। चीजें पसंद करती हैं दिनांक स्वरूपण और स्ट्रिंग हेरफेर बस SQL में चूसते हैं, आप PHP में उस काम को बेहतर तरीके से कर रहे हैं।
मूल रूप से, प्रत्येक सिस्टम का उपयोग उस काम के लिए करें जो इसे करने के लिए बनाया गया है।
रख-रखाव के संदर्भ में, जब तक कि क्या होता है, जहां स्पष्ट होता है, के बीच का विभाजन, इन्हें तर्क के प्रकारों से अलग करने से अधिक समस्या नहीं होनी चाहिए और निश्चित रूप से लाभों को बाहर करने के लिए पर्याप्त नहीं होना चाहिए। मेरी राय में सभी तर्कों को एक ही स्थान पर रखने की तुलना में कोड स्पष्टता और रखरखाव स्थिरता के बारे में अधिक है।
पुन:विशिष्ट उदाहरण...
-
मुझे पता है कि यह वह नहीं है जिसका आप भी जिक्र कर रहे हैं, लेकिन तारीखें लगभग एक विशेष मामला है। आप यह सुनिश्चित करना चाहते हैं कि सिस्टम द्वारा उत्पन्न सभी तिथियां या तो वेब सर्वर या डेटाबेस पर बनाई गई हैं। यदि डीबी सर्वर और वेबसर्वर कभी भी अलग-अलग टाइमज़ोन के लिए कॉन्फ़िगर किए जाते हैं (मैंने ऐसा होता देखा है) तो अन्यथा कुछ कपटी बग का कारण बन जाएगा। कल्पना कीजिए, उदाहरण के लिए, आपके पास एक
createdDateहैgetDate(). के डिफ़ॉल्ट के साथ कॉलम जो डालने पर लागू होता है DB द्वारा . यदि आप एक रिकॉर्ड डालने वाले थे, तो PHP में . उत्पन्न तिथि का उपयोग करके (जैसेdate("Y-m-d", time() - 3600), अंतिम घंटे में बनाए गए रिकॉर्ड का चयन करें, हो सकता है कि आपको वह न मिले जिसकी आप अपेक्षा करते हैं। आपको यह किस परत पर करना चाहिए, मैं डीबी के पक्ष में हूं, उदाहरण के लिए, यह आपको कॉलम डिफ़ॉल्ट का उपयोग करने देता है। -
अधिकांश ऐप्स के लिए मैं इसे PHP में करूँगा। पहले नाम और उपनाम का मेल तब तक आसान लगता है जब तक आपको एहसास नहीं हो जाता कि आपको कभी-कभी अभिवादन, शीर्षक और मध्य आद्याक्षर की भी आवश्यकता होती है। इसके अलावा आप लगभग निश्चित रूप से ऐसी स्थिति में समाप्त होने जा रहे हैं जहां आप उपयोगकर्ता का पहला नाम, उपनाम और एक संयोजन अभिवादन + प्रथम नाम + उपनाम चाहते हैं। उन्हें डीबी-साइड से जोड़ने का मतलब है कि आप अधिक डेटा ले जा रहे हैं, हालांकि वास्तव में, यह बहुत मामूली है।
-
निर्भर करता है। ऊपर के रूप में, यदि आप कभी भी उन्हें अलग से उपयोग करना चाहते हैं, तो आप प्रदर्शन के लिहाज से बेहतर हैं कि उन्हें अलग से बाहर निकालें और जरूरत पड़ने पर संयोजित करें। उस ने कहा, जब तक आपके साथ काम करने वाले डेटासेट बहुत बड़े नहीं होते हैं, तो संभवतः अन्य कारक होते हैं (जैसे, जैसा कि आप उल्लेख करते हैं, रखरखाव) जिनका अधिक असर होता है।
अंगूठे के कुछ नियम:
- बढ़ते आईडी बनाना डीबी में होना चाहिए।
- व्यक्तिगत रूप से, मुझे डीबी द्वारा लागू मेरा डिफ़ॉल्ट पसंद है।
- चयन करते समय, रिकॉर्ड की संख्या को कम करने वाली कोई भी चीज़ DB द्वारा की जानी चाहिए।
- आमतौर पर ऐसी चीजें करना अच्छा होता है जो डेटासेट डीबी-साइड के आकार को कम करती हैं (जैसे ऊपर स्ट्रिंग्स उदाहरण के साथ)।
- और जैसा आप कहते हैं; आदेश देना, एकत्रीकरण, उप-प्रश्न, जुड़ना आदि हमेशा डीबी-साइड होना चाहिए।
- इसके अलावा, हमने उनके बारे में बात नहीं की है लेकिन ट्रिगर आमतौर पर खराब/आवश्यक होते हैं।
यहां कुछ प्रमुख ट्रेड-ऑफ हैं जिनका आप सामना कर रहे हैं और शेष राशि वास्तव में आपके आवेदन पर निर्भर करती है।
एसक्यूएल में कुछ चीजें निश्चित रूप से-हमेशा-हमेशा की जानी चाहिए। बहुत सारे कार्यों के लिए कुछ अपवादों (जैसे तारीखों की बात) को छोड़कर SQL बहुत भद्दा हो सकता है और आपको तर्क के साथ बाहर के स्थानों में छोड़ सकता है। किसी विशिष्ट कॉलम के संदर्भ के लिए अपना कोडबेस खोजते समय (उदाहरण के लिए) यह है दृश्य या संग्रहीत कार्यविधि में शामिल लोगों को आसानी से याद किया जा सकता है।
प्रदर्शन हमेशा एक विचार है लेकिन, आपके ऐप और विशिष्ट उदाहरण के आधार पर, शायद बड़ा नहीं है। रख-रखाव के बारे में आपकी चिंताएँ और शायद बहुत मान्य हैं और कुछ प्रदर्शन लाभों का मैंने उल्लेख किया है, इसलिए समयपूर्व अनुकूलन से सावधान रहें।
साथ ही, यदि अन्य सिस्टम सीधे डीबी तक पहुंच रहे हैं (उदाहरण के लिए रिपोर्टिंग, या आयात/निर्यात के लिए) तो आपको डीबी में अधिक तर्क होने से लाभ होगा। उदाहरण के लिए, यदि आप किसी अन्य डेटा स्रोत से उपयोगकर्ताओं को सीधे आयात करना चाहते हैं, तो ईमेल सत्यापन फ़ंक्शन जैसा कुछ पुन:प्रयोज्य होगा जिसे SQL में लागू किया गया है।
संक्षिप्त उत्तर:यह निर्भर करता है। :)
