"कभी भी उस कोड में न करें जो आपको आपके लिए अच्छा करने के लिए SQL सर्वर प्राप्त कर सकता है" - क्या यह एक खराब डिजाइन का नुस्खा है?

Question

यह एक ऐसा विचार है जिसे मैंने कई स्थानों पर दोहराया है। कमोबेश कुछ लोग यह स्वीकार करते हैं कि एक बार पूरी तरह से SQL में किसी समस्या को हल करने की कोशिश करने से जटिलता का एक निश्चित स्तर पार हो जाता है जिसे आपको वास्तव में कोड में संभालना चाहिए।

इस विचार के पीछे तर्क यह है कि अधिकांश मामलों के लिए, डेटाबेस इंजन आपके कार्य को पूरा करने के सबसे कुशल तरीके को खोजने में एक बेहतर काम करेगा, जितना आप कोड में कर सकते हैं। खासकर जब यह डेटा पर किए गए संचालन पर परिणामों को सशर्त बनाने जैसी चीजों की बात करता है। प्रभावी रूप से आधुनिक इंजनों के साथ प्रभावी ढंग से JIT'ing + आपकी क्वेरी के संकलित संस्करण को कैशिंग करता है जो सतह पर इसका अर्थ होगा।

सवाल यह है कि इस तरह से अपने डेटाबेस इंजन का लाभ उठाएं या नहीं, स्वाभाविक रूप से खराब डिजाइन अभ्यास (और क्यों) है। सभी लॉजिक डेटाबेस के अंदर मौजूद होने पर लाइनें और धुंधली हो जाती हैं और आप इसे केवल ORM के माध्यम से हिट कर रहे हैं।

Comments

यह उन कथनों में से एक है जिसे सोच समझकर लिया जाना चाहिए। जब भी कोई दूसरे इंजीनियर को टेबल से 'सिलेक्ट * करता है, तब उसे बाहर निकाल दिया जाता है और फिर एक क्लॉज और निर्दिष्ट कॉलम का उपयोग करने के बजाय परिणाम सेट के माध्यम से कंघी करता है। लेकिन अगर आप इसे बहुत दूर ले जाते हैं, तो आप एक अलग गड़बड़ करते हैं।

— माइकल कोहेन

"कभी नहीं" या "हमेशा" के साथ एक वाक्यांश शुरू करना लगभग हमेशा एक खराब डिजाइन के लिए एक नुस्खा है।

— १

हालांकि एसक्यूएल में बहुत अधिक करने की कोशिश करना निश्चित रूप से संभव है, मैं ईमानदारी से कह सकता हूं कि विकास और परामर्श के 30 वर्षों में, मैंने कभी भी इसके (कुछ मामूली) एक वास्तविक गंभीर मामले को नहीं देखा है। दूसरी ओर, मैंने सचमुच डेवलपर्स के सैकड़ों गंभीर मामलों को "कोड" में बहुत कुछ करने की कोशिश करते देखा है जो उन्हें एसक्यूएल में करना चाहिए था। और मैं अभी भी उन्हें देखता हूं। अक्सर ...

— RBarryYoung

@MrEdmundo इसे मेटा में ले जाएं।

— ta.speot.is

यह प्रश्न दो में एक है - मुझे लगता है कि इसे विभाजित किया जाना चाहिए। 1) SQL में कितना होना चाहिए? 2) DBMS में कितना होना चाहिए? संग्रहीत प्रक्रियाएं बीच में आती हैं। मैंने पूरे अनुप्रयोगों को संग्रहीत प्रक्रियाओं में कोडित देखा है।

— रिस्टोरियरपोस्ट

Answer 1

आम आदमी के शब्दों में:

ये ऐसी चीजें हैं जो एसक्यूएल करने के लिए बनाई गई हैं और, यह मानें या नहीं, मैंने कोड में देखा है:

• जुड़ता है - कोडवाइज़ इसके लिए जटिल सरणी हेरफेर की आवश्यकता होगी
• फ़िल्टरिंग डेटा (जहाँ) - कोडवाइज़ के लिए सूचियों में भारी डालने और वस्तुओं को हटाने की आवश्यकता होगी
• कॉलम का चयन करना - कोडाइज़ करने के लिए भारी सूची या सरणी हेरफेर की आवश्यकता होगी
• कुल कार्य - कूटकरण के लिए इसे मानों और जटिल स्विच मामलों को रखने के लिए सरणियों की आवश्यकता होगी
• विदेशी कुंजी अखंडता - कोडवर्ड यह सम्मिलित करने से पहले प्रश्नों की आवश्यकता होगी और मानता है कि कोई भी ऐप के बाहर डेटा का उपयोग नहीं करेगा
• प्राथमिक कुंजी अखंडता - कोडवर्ड यह डालने से पहले प्रश्नों की आवश्यकता होगी और मानता है कि कोई भी ऐप के बाहर डेटा का उपयोग नहीं करेगा

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

Comments

[phone] यह इंगित करने के लिए कि यह खतरनाक रूप से मानता है कि सब कुछ केवल एप्लिकेशन के माध्यम से होगा।

— HLGEM

@skynorth यह खराब डेटाबेस डिज़ाइन की ओर ले जाता है। रेखा के नीचे आप एक डेटाबेस है जिसके साथ खत्म हो सकता है केवल सब के बाद प्रसंस्करण यह होता है की वजह से है कि आवेदन के द्वारा सार्थक पहुँचा जा।

— सेरेक्स

@skynorth यदि आप यह सुनिश्चित करने के लिए कोड पर भरोसा करते हैं कि आपकी चाबियाँ अखंडता बनाए रखती हैं, तो आप DB से एक मूल सिद्धांत RDBMS निकाल रहे हैं। इसका कोई मतलब नहीं है, क्योंकि तब डीबी तक पहुंचने वाले प्रत्येक एप्लिकेशन को उस कार्यक्षमता को ठीक से दोहराने के लिए सुनिश्चित करना होगा। सिर्फ डीबी को ही क्यों न संभालें, क्योंकि यह उसी के लिए बनाया गया है। उदाहरण के लिए DB डुप्लिकेट कुंजियों को मूल रूप से रोक सकता है।

— बुटिक बटुक

लेनदेन मत भूलना!

— स्किलिव्ज

@skynorth: tl; dr: आपके डेटा को सुसंगत रखने वाले नियमों को डेटाबेस में लागू किया जाना चाहिए। कभी लिखे गए 99% अनुप्रयोगों के लिए, आपके आवेदन के मृत होने और चले जाने के बाद डेटा (और इसलिए डेटाबेस) looooooooooong रहता है। मैंने इसे कई बार देखा है, कई बार वर्षों से नीचे (अरे, हमें विंडोज / आईफोन / एंड्रॉइड / जो भी नया-नया है, पर एक संस्करण को तैनात करने की आवश्यकता है, क्योंकि {पुराने प्लेटफॉर्म को यहां डालें} मर रहा है, हम ' यहाँ होस्ट या ओरेकल डेटाबेस करेंगे और वहाँ एक नया यूआई बनाएँ )। इस प्रवृत्ति को रोकने के लिए आज या किसी भी समय जल्द ही कोई कारण नहीं है।

— बाइनरी वॉरियर

Answer 2

मुझे लगता है कि "SQL सर्वर क्या आप के लिए अच्छी तरह से कर सकते हैं कोड में कभी नहीं" rephrase होगा ।

स्ट्रिंग हेरफेर, रेगेक्स काम और जैसे मैं SQL सर्वर (SQL CLR को छोड़कर) में नहीं करूंगा।

उपरोक्त चीजों के बारे में बात करने के लिए जाता है जैसे - जुड़ता है, संचालन और क्वेरी सेट करता है। इसके पीछे इरादा SQL सर्वर को भारी उठाने का बहुत कुछ सौंपना है (चीजों पर यह अच्छा है) और जितना संभव हो उतना IO की मात्रा कम करें (इसलिए SQL ज्वाइन करें और एक WHEREक्लॉज के साथ फ़िल्टर करें , बहुत कुछ वापस लौटाएं अन्यथा की तुलना में छोटा डेटा सेट)।

Comments

अगर सबकुछ SQL बेहतर होगा, तो एप्लिकेशन कोड को SQL लेयर में डाल दिया जाता है, बहुत से व्यावसायिक तर्क हैं जो डेटाबेस में बेहतर या बदतर के लिए समाप्त होंगे। मैंने इसे देखा है और हां, प्रदर्शन में तेजी थी। लेकिन सौभाग्य से देव टीम सभी एप्लिकेशन विकास और एसक्यूएल को अच्छी तरह से जानते थे क्योंकि दोनों के बीच की सीमा बहुत ही अनाकार हो गई थी। मैं इसे एक शुरुआती बिंदु के रूप में नहीं सुझाऊंगा, बल्कि सिस्टम के बाद एक अंतिम बिंदु के रूप में काफी लोकप्रिय हो जाएगा और समय के साथ प्रदर्शन में गिरावट आएगी।

— जिमी होफा

पाठ्यक्रम के लिए घोड़े guv?

— स्परुपर

@NathanLong मुझे नहीं पता कि इतने सारे लोग अभी भी क्यों सोचते हैं कि आप अपने SQL को स्रोत नियंत्रण में नहीं रख सकते। पहले तो हमारे पास स्रोत नियंत्रण में डेटाबेस को बनाने के लिए हमारी सभी संग्रहीत कार्यविधियाँ / टेबल स्क्रिप्ट / आदि आवश्यक थीं, फिर बाद में विज़ुअल स्टूडियो डेटाबेस प्रोजेक्ट्स का उपयोग किया गया। इसने परियोजनाओं के बिना ठीक काम किया और उनके साथ बेहतर किया। आपके सिस्टम को बनाने के लिए आवश्यक हर दूसरी परिवर्तनशील चीज़ के साथ SQL संस्करण नियंत्रण में होना चाहिए! यदि आप अपनी नियंत्रण स्क्रिप्ट्स को संस्करण नियंत्रण में रखते हैं, तो तैनाती को अधिकांश RDBMS के लिए Redgate diff टूल के साथ किया जा सकता है, अलग-अलग स्क्रिप्ट्स का उपयोग न करें

— जिमी होफा

यदि आपके SQL में REGEX संचालन और स्ट्रिंग हेरफेर के लिए समर्थन है, तो उन्हें SQL में करना एक अच्छा विकल्प हो सकता है।

— केविन क्लाइन

@NathanLong: इसे इस तरह से समझें, एक DB तालिका एक पाठ फ़ाइल में लिखे कोड के एक अंश द्वारा परिभाषित की गई है, वाक्यविन्यास "तालिका बनाएँ ..." की तर्ज पर है। अब आप अपनी पसंद की SCM में उस टेक्स्ट फ़ाइल को स्टोर कर सकते हैं, जैसे कि यदि आपके पास अपनी पसंदीदा ऐप भाषा में DB टेबल क्रिएशन कोड है, जो भी API की आवश्यकता होती है उसे कॉल करता है, और आप उस टेक्स्ट फ़ाइल को अपने SCM में स्टोर कर लेंगे। मुझे लगता है कि एक समस्या यह है कि कुछ लोगों को लगता है कि डीबी किसी तरह जादू जानवर हैं, और वे केवल वीबी कोड (या जो भी) लिखना जानते हैं और इसलिए वे केवल उस आवेदन भाषा के संदर्भ में सोचते हैं जिसे वे जानते हैं।

— gbjbaanb 18

Answer 3

कोड आप एसक्यूएल सर्वर करने के लिए प्राप्त कर सकते हैं क्या में क्या कभी अच्छी तरह से आप के लिए (जोर मेरा है)

उत्तर की कुंजी आपको एसक्यूएल के लिए कुछ अच्छी तरह से देखने की जरूरत है, जैसा कि केवल आपके लिए कुछ करने का विरोध किया गया है। एसक्यूएल एक अद्भुत शक्तिशाली भाषा है। अंतर्निहित कार्यों के साथ युग्मित, यह संभवतः बहुत सारी चीजें कर सकता है। हालाँकि, यह तथ्य कि आप SQL में कुछ कर सकते हैं, वास्तव में SQL में ऐसा करने के लिए कोई बहाना नहीं होना चाहिए।

निर्णय लेने के लिए मेरा विशिष्ट मानदंड है कि आपको प्राप्त होने वाली डेटा की मात्रा और राउंड-ट्रिप की संख्या को देखना है: यदि आप सर्वर पर किसी कार्य को शिपिंग करके डेटा की मात्रा में कटौती कर सकते हैं, बिना राउंड की संख्या बढ़ाए- यात्राएं, फिर कार्य सर्वर पर होता है; यदि राउंड-ट्रिप की संख्या में एक साथ गिरावट के बिना डेटा की मात्रा समान रहती है या बढ़ जाती है, तो कार्य आपके कोड में है।

इन उदाहरणों पर विचार करें:

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

Comments

जब मैंने कहीं काम किया तो व्यापार तर्क एसक्यूएल के साथ अनाकार हो गया, हमें कई दौर की यात्राओं से कोई परेशानी नहीं थी; हमने सिर्फ एक ही राउंड ट्रिप में कई रिजल्ट सेट का इस्तेमाल किया, ताकि नियम थोड़े टूट जाएं, हालांकि गोल्डन मीन के लिए नियम की भावना बहुत अच्छी है

— जिमी हॉफ

+1 यह एक शानदार जवाब है क्योंकि यह दोनों दिशाओं का समर्थन करने के लिए ठोस उदाहरण देता है।

— ब्रैंडन

अपने दूसरे उदाहरण पर। आप क्या कहते हैं, यदि परिदृश्य निम्नानुसार है- उपयोगकर्ता और बीडा कैश हैं और कहते हैं कि रिकॉर्ड आकार 1000-2000 की सीमा में है। क्या यह अधिक तेज नहीं है मेमोरी में कोई db कॉल आवश्यक नहीं है क्योंकि डेटा को कैश किया गया है और इसलिए 'sql ऑपरेशन' के बीच से बचा जाता है। प्रसंस्करण स्मृति में 1000 + उपयोगकर्ताओं की सूची के माध्यम से पुनरावृत्त होगा और यह पता लगाएगा कि मैच कहां होता है। यह db में कर से तेज नहीं होगा

— user4677228

@ user4677228 लेकिन स्केलिंग का प्रयास करें :- पी। यदि आपके कोड को सभी उम्र की गणना करने के लिए सभी डेटा को स्कैन करना है और आपका वांछित परिणाम सिर्फ "कितने उपयोगकर्ता कम से कम 20 और 30 से कम उम्र के हैं?", तो कैश आपको बिल्कुल भी मदद नहीं करेगा। आप अभी भी अपने ग्राहक को पूरी तालिका स्ट्रीमिंग करेंगे, लेकिन डेटाबेस सर्वर अपनी मेमोरी / कैश में यह सब कर सकता है और आपको इस बात की परवाह किए बिना एक तेज़ उत्तर देगा कि क्या db क्लाइंट स्थानीय सॉकेट्स के माध्यम से कनेक्ट हो रहा है या नेटवर्क पर दूरस्थ रूप से यदि आप एक WHEREखंड में उम्र की गणना करने के लिए तैयार हैं ।

— 21-30 बजे बिंकी जू

Answer 4

संक्षेप में , यह कहना सही होगा कि: " अपने कोड बेस में डेटाबेस विशिष्ट संचालन कभी न करें" क्योंकि वे आपके डेटाबेस में बेहतर तरीके से संबोधित होते हैं।

सेट बेस ऑपरेशन के उदाहरण को देखें । जैसा कि आप जानते हैं, RDBMS एक सामान्य डेटा संग्रहण और हेरफेर संचालन को संभालने के लिए बनाए जाते हैं।

इसके अलावा, डेटाबेस की परियोजना पसंद महत्वपूर्ण भूमिका निभाती है । RDBMS (MS SQL, Oracle, इत्यादि) होना रेनबीडी जैसे NoSQL डेटाबेस से अलग है।

Comments

कभी भी अपने कोड बेस में सेट ऑपरेशंस को रखने का मतलब यह नहीं होगा कि LINQ में कलेक्शंस (सेलेक्ट, सम, जहाँ, सिंगल) में सब कुछ एसक्यूएल में किया जाना चाहिए और आपके ऐप में नहीं होना चाहिए , इससे आपके डेटाबेस में बहुत से लॉजिक हो जाएंगे।

— जिम्मी हॉफ

जिन चीजों का आप वर्णन करते हैं, वे क्लाइंट कोड नहीं हैं। यह एक व्यवसायिक परत है, जहां आपके पास अपने स्वयं के हेरफेर तर्क हो सकते हैं। हालाँकि 1M + रिकॉर्ड्स पर इस तर्क का प्रदर्शन आपको पीछे छोड़ने वाला है।

— ईएल यूसुबोव

@ जिमीहॉफ: यह सच नहीं है, कभी-कभी आप क्षणिक जानकारी उत्पन्न करते हैं, जिसे आपके पास पहले से मौजूद ऐप मेमोरी पर डेटा के साथ संसाधित करने की आवश्यकता होती है। Linq उस पर अद्भुत काम करता है।

— फैब्रिकियो अरुजो

@FabricioAraujo मैं इस बात से अवगत हूँ कि linq महान क्यों है, लेकिन यह उत्तर बताता है कि कभी भी ऐप कोड में आधारित संचालन नहीं करना चाहिए, यदि आपने कभी भी ऐप कोड में संचालन सेट नहीं किया तो आप कभी भी linq का उपयोग नहीं करेंगे क्योंकि यह linq का संपूर्ण उद्देश्य है। मैं बात कर रहा हूं कि कभी भी ऐप कोड में ऑपरेशन नहीं करना एक बुरा नियम है

— जिमी हॉफ

@ जिमीहॉफ: नहीं, नियम कहता है "कभी भी ऐप में ऐसा न करें कि RDBMS आपके लिए क्या अच्छा कर सकता है"। और मैं क्षणिक जानकारी के बारे में बात कर रहा हूं - डेटाबेस पर जारी जानकारी नहीं। मैंने उन प्रणालियों पर काम किया, जहां व्यावसायिक नियमों को पूर्ण करने के लिए, मुझे कोड पर प्रसंस्करण करने की आवश्यकता थी। मुझे एक व्यवसाय नियम याद है जो मेरे पास था, DB पर भारी प्रसंस्करण करने के बाद, एक (बहुत महत्वपूर्ण) रिपोर्ट उत्पन्न करने के लिए उस डेटा पर अतिरिक्त प्रसंस्करण करते हैं। मैं जो मैं उस पर linq का उपयोग कर सकता था (यह अब-दोषपूर्ण Delphi.Net पर किया गया था)। दूसरे शब्दों में, उस नियम का पालन करते हुए भी linq का उपयोग किया जा सकता है।

— फैब्रिकियो अरुजो

Answer 5

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

लेकिन आपके उत्पाद के पैमाने के रूप में, यह आमतौर पर आपके एप्लिकेशन को आपके db को स्केल करने की तुलना में आसान बनाता है। बड़े इंस्टॉलेशन में, 10 से 1 या अधिक के कारक द्वारा एप्लिकेशन सर्वर आउटनंबर डेटाबेस सर्वरों को देखना असामान्य नहीं है। अधिक एप्लिकेशन सर्वर जोड़ना अक्सर नए हार्डवेयर पर मौजूदा सर्वर को क्लोन करने का एक सरल मामला है। दूसरी ओर, नए डेटाबेस सर्वर को जोड़ना ज्यादातर मामलों में नाटकीय रूप से अधिक कठिन है।

तो इस बिंदु पर, मंत्र डेटाबेस की रक्षा करता है । यह पता चलता है कि डेटाबेस के परिणामों को कैशिंग करके memcachedया एप्लिकेशन-साइड लॉग में अपडेट को कॉपी करके, या डेटा को एक बार प्राप्त करके और अपने ऐप में अपने आँकड़ों की गणना करके, आप अपने डेटाबेस के कार्यभार को नाटकीय रूप से कम कर सकते हैं, जिससे आपको सहारा लेना पड़ता है एक और भी अधिक जटिल और नाजुक डीबी क्लस्टर कॉन्फ़िगरेशन।

Comments

पैसा हार्डवेयर स्केलेबिलिटी मुद्दों को हल कर सकता है, जबकि कोई भी राशि सॉफ्टवेयर जटिलता को हल नहीं कर सकती है।

— ट्यूलेंस कोरडोवा

@ user1598390 वास्तव में: हार्डवेयर सस्ता है, प्रोग्रामर महंगे हैं । पैसा सॉफ्टवेयर जटिलता को हल कर सकता है। प्रोग्रामरों पर खर्च किया गया पैसा। लेकिन ध्यान दें कि हम स्वच्छ कोड बनाम स्पेगेटी के बारे में बात नहीं कर रहे हैं। हम ऐप की ओर बनाम डीबी साइड में काम करने के बारे में बात कर रहे हैं। सॉफ्टवेयर जटिलता केवल मामूली रूप से संबंधित है, क्योंकि दोनों विकल्प अच्छे डिजाइन सिद्धांतों का पालन कर सकते हैं। एक बेहतर सवाल यह है: " किस डिजाइन की कीमत अधिक है? "।

— tylerl

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

— ट्यूलेंस कोरडोवा

आपके उत्तर में स्केलिंग का उल्लेख करने वाला एकमात्र व्यक्ति होने के लिए +1।

— मैट

हार्डवेयर सस्ता था, अब और नहीं - डेटासेंटर में, बिजली और हार्डवेयर की मात्रा चल रही लागत का 88% (Microsoft द्वारा उद्धृत) इसलिए कुशल कोड लिखने के लिए प्रोग्रामर पर अधिक खर्च करना बहुत ही प्रभावी है, और तब तक रहेगा जब तक हम असीमित न हों और सस्ती संलयन शक्ति।

— gbjbaanb

Answer 6

मुझे लगता है कि यह उन चीजों के लिए डेटाबेस का उपयोग नहीं करने के लिए खराब डिजाइन होगा जो इसके लिए है। मैंने कभी भी ऐसा कोई डेटाबेस नहीं देखा है जहाँ डेटाबेस के बाहर नियम लागू किए गए थे जिसमें अच्छा डेटा था। और मैंने सैकड़ों डेटाबेस देखे हैं।

तो ऐसी चीजें जो डेटाबेस में होनी चाहिए:

• ऑडिटिंग (केवल ऑडिटिंग डेटाबेस में सभी परिवर्तनों को ट्रैक नहीं करेगा और इस प्रकार बेकार है)।

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

• जॉन्स और जहां क्लॉज फ़िल्टरिंग (नेटवर्क में भेजे गए रिकॉर्ड की संख्या को कम करने के लिए)

Answer 7

"समय से पहले का अनुकूलन कंप्यूटर प्रोग्रामिंग में सभी बुराई (इसका अधिकांश, वैसे भी) का मूल है" - डोनाल्ड नथ

डेटाबेस बिल्कुल यही है; आपके एप्लिकेशन की डेटा परत। इसका काम आपके आवेदन के लिए दिए गए डेटा के साथ प्रदान करना है, और इसे दिए गए डेटा को संग्रहीत करना है। आपका एप्लिकेशन कोड डालने का स्थान है जो वास्तव में डेटा के साथ काम करता है; इसे प्रदर्शित करना, इसे मान्य करना, आदि।

जबकि शीर्षक पंक्ति में भावना सराहनीय है, और एक बात करने के लिए सटीक है (छानने के बुनियादी तथ्य, पेश, समूहीकरण आदि चाहिए मामलों की भारी संख्या में डीबी लिए छोड़ दिया जाना), में हो सकता है की "अच्छी तरह से" एक परिभाषा गण। SQL सर्वर निष्पादन के उच्च स्तर के साथ कार्य कर सकता है, लेकिन वे कार्य जो आप प्रदर्शित कर सकते हैंSQL सर्वर एक अलग-थलग तरीके से सही ढंग से करता है, दोहराने योग्य तरीके बहुत कम हैं। SQL प्रबंधन स्टूडियो एक महान डेटाबेस आईडीई है (विशेष रूप से अन्य विकल्प जो मैंने TOAD की तरह काम किया है) को देखते हुए, लेकिन इसकी सीमाएँ हैं, उनमें से सबसे पहले यह है कि आप इसे करने के लिए इसका उपयोग करते हैं (या किसी भी प्रक्रियात्मक कोड को आप निष्पादित करते हैं) DB नीचे) एक "साइड इफ़ेक्ट" (आपकी प्रक्रिया की मेमोरी स्पेस के डोमेन के बाहर स्थित अवस्था में परिवर्तन) की परिभाषा के द्वारा है। इसके अलावा, SQL सर्वर के भीतर प्रक्रियात्मक कोड केवल अब है, नवीनतम IDEs और टूल के साथ, जिस तरह से प्रबंधित कोड को कवरेज मैट्रिक्स और पथ विश्लेषण का उपयोग करके मापा जा सकता है (ताकि आप यह प्रदर्शित कर सकें कि यह विशेष रूप से तब होता है जब परीक्षण X द्वारा बयान का सामना किया जाता है। , Y, और Z, और परीक्षण X को स्थिति को सत्य बनाने और उस आधे को निष्पादित करने के लिए डिज़ाइन किया गया है जबकि Y और Z "और" निष्पादित करते हैं । यही कारण है कि बदले में, आपके पास एक ऐसा परीक्षण होता है जो डेटाबेस को एक विशेष प्रारंभिक स्थिति के साथ सेट कर सकता है, कुछ प्रक्रिया के माध्यम से डेटाबेस प्रक्रियात्मक कोड को निष्पादित कर सकता है, और अपेक्षित परिणामों को पूरा कर सकता है।

यह सब बहुत अधिक कठिन है और अधिकांश डेटा एक्सेस परतों द्वारा प्रदान किए गए समाधान से शामिल है; डेटा लेयर मानें (और, उस बात के लिए, DAL) को पता है कि सही इनपुट दिए जाने पर अपना काम कैसे करना है, और फिर परीक्षण करें कि आपका कोड सही इनपुट प्रदान करता है। SPs जैसे प्रक्रियात्मक कोड को रखने और DB से बाहर ट्रिगर करने के बजाय और आवेदन कोड में उन प्रकार की चीजों को करने से, आवेदन कोड व्यायाम करने के लिए बहुत आसान है।

Comments

रुको, रुको, क्या? आपको शुद्धता प्रमाण से लेकर परीक्षण तक कैसे प्राप्त हुए, जो यह साबित कर सकते हैं कि बग मौजूद हैं लेकिन कभी भी यह साबित नहीं कर सकते कि कोड सही है?

— मेसन व्हीलर

एक संग्रहीत प्रक्रिया प्रक्रियात्मक कोड नहीं है। एक SP एक पूर्व-संगणित SQL क्वेरी है जिसे DB के अंदर संग्रहीत और चलाया जाता है। यह एप्लिकेशन कोड नहीं है।

— gbjbaanb 14

यदि SP SQL क्वेरी तक सीमित है, तो आप सही हैं। यदि यह सशर्त विराम, लूप, कर्सर और / या अन्य गैर-क्वेरी तर्क सहित T-SQL या PL / SQL है, तो आप गलत हैं। और साइबर स्पेस पर डीबी में एसपी, फ़ंक्शंस और ट्रिगर्स के बहुत सारे अतिरिक्त तत्व होते हैं।

— कीथ्स

Answer 8

जिन चीजों को लोग महसूस नहीं करते हैं उनमें से एक यह है कि SQL सर्वर पर आपके सभी प्रसंस्करण करना आवश्यक नहीं है, कोड गुणवत्ता पर प्रभाव की परवाह किए बिना।

उदाहरण के लिए, यदि आपको कुछ डेटा हड़पने की जरूरत है और फिर डेटा से कुछ की गणना करें और फिर उस डेटा को डेटाबेस में स्टोर करें। दो विकल्प हैं:

• अपने एप्लिकेशन में डेटा को पकड़ो, अपने एप्लिकेशन के भीतर गणना करें और फिर डेटा को डेटाबेस में वापस भेजें
• संग्रहीत कार्यविधि या डेटा को हथियाने के लिए समान है, उस पर गणना करें, और फिर इसे सभी कॉल से SQL सर्वर पर संग्रहीत करें।

आप सोच सकते हैं कि दूसरा समाधान हमेशा सबसे तेज़ होता है, लेकिन यह निश्चित रूप से सच नहीं है। मैं भले ही SQL समस्या (यानी regex और स्ट्रिंग हेरफेर) के लिए एक बुरा फिट हूँ अनदेखा कर रहा हूँ। आइए दिखाते हैं कि आपके पास SQL ​​CLR है या डेटाबेस में एक शक्तिशाली भाषा के समान कुछ भी है। यदि एक गोल यात्रा करने के लिए 1 सेकंड लगता है और डेटा प्राप्त करने के लिए और इसे संग्रहीत करने के लिए 1 सेकंड मिलता है, और फिर इसके पार कम्प्यूटरीकरण करने के लिए 10 सेकंड। यदि आप यह सब डेटाबेस में कर रहे हैं तो आप गलत कर रहे हैं।

ज़रूर, आप 2 सेकंड शेव करें। हालाँकि, क्या आपने 10 सेकंड के लिए अपने डेटाबेस सर्वर पर 100% (कम से कम) एक सीपीयू कोर बर्बाद किया था, या आपने उस समय को अपने वेब सर्वर पर बर्बाद किया था?

वेब सर्वर को स्केल करना आसान है, दूसरी ओर डेटाबेस बेहद महंगे हैं, खासकर SQL डेटाबेस। ज्यादातर समय, वेब सर्वर "स्टेटलेस" होते हैं और इन्हें जोड़ा जा सकता है और किसी भी अतिरिक्त लोड बैलेंसर के लिए कोई अतिरिक्त कॉन्फ़िगरेशन नहीं दिया जा सकता है।

इसलिए, केवल एक ऑपरेशन से 2 सेकंड शेविंग के बारे में न सोचें, बल्कि स्केलेबिलिटी के बारे में भी सोचें। जब आप अपेक्षाकृत छोटे प्रदर्शन प्रभाव के साथ बहुत सस्ता वेब सर्वर संसाधनों का उपयोग कर सकते हैं तो डेटाबेस सर्वर संसाधनों जैसे महंगे संसाधनों को बर्बाद क्यों करें

Comments

आप नेटवर्क यात्रा भी भूल रहे हैं - आप कुछ दक्षता हिट के बिना सर्वर जोड़कर क्षैतिज पैमाने पर नहीं कर सकते। इसलिए एक क्लॉज जोड़कर डेटा लोड को कम करना स्पष्ट है - लेकिन अन्य एसक्यूएल संचालन जरूरी नहीं कि प्रदर्शन को कम करेगा। आपकी बात सामान्य रूप से सही है, लेकिन उस बिंदु पर नहीं जहां आप DB को एक दबंग दस्तोर के रूप में मानते हैं। सबसे अधिक स्केलेबल ऐप मैंने कभी भी हर डेटा कॉल के लिए उपयोग की गई संग्रहीत प्रक्रियाओं पर काम किया है (2 जटिल प्रश्नों को छोड़कर)। एक तीसरा समाधान सबसे अच्छा है - "केवल आवश्यक डेटा हड़पने के लिए संग्रहित खरीदारी", यह सुनिश्चित करने के लिए कि आपका मतलब 'गणना' है या नहीं।

— gbjbaanb 14

Answer 9

मैं इसे देखना पसंद करता हूं क्योंकि एसक्यूएल को केवल डेटा से ही निपटना चाहिए। व्यवसाय नियम जो तय करते हैं कि क्वेरी क्या दिख सकती है कोड में हो सकती है। इन्फॉर्मिटॉन का रेगेक्स या सत्यापन कोड में किया जाना चाहिए। एसक्यूएल को केवल आपकी तालिका में शामिल होने के लिए छोड़ दिया जाना चाहिए, अपने डेटा को क्वेरी करें, स्वच्छ डेटा डालें, आदि।

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

बस मेरे $ 0.02 हालांकि।

Comments

आप डेटाबेस में पहले से मौजूद डेटा पर रेगेक्स या सत्यापन क्यों चलाएंगे? बाधाओं को कभी भी खराब होने से रोकना चाहिए, और रेगेक्स के उपयोग का मतलब है कि आपको अधिक उपयोगी स्तंभों की आवश्यकता है ..

— ब्रेंडन लांग

मैं यह नहीं कह रहा था कि मैं डेटाबेस से आने वाले डेटा पर रेगेक्स या सत्यापन का उपयोग करूंगा। मुझे लगता है कि मुझे स्पष्ट करना चाहिए था कि डेटाबेस में जाने वाले डेटा के लिए था। मेरा कहना यह था कि डीएएल में जाने से पहले डेटा को साफ और मान्य किया जाना चाहिए।

— स्टेनली ग्लास जूनियर

Answer 10

आम तौर पर मैं सहमत हूं कि कोड को व्यापार तर्क को नियंत्रित करना चाहिए और डीबी को तर्क मुक्त हैश होना चाहिए। लेकिन यहाँ कुछ काउंटर पॉइंट दिए गए हैं:

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

क्या आपके नियंत्रण से बाहर अन्य पार्टियां डेटाबेस को स्पर्श करती हैं? यदि ऐसा हो तो डेटा के करीब आने में अड़चन अच्छी है। पहुंच एक वेब-सेवा तक सीमित हो सकती है जो तर्क को लागू करती है, लेकिन यह मानती है कि आप "पहले" थे और अन्य दलों पर सेवा के उपयोग को लागू करने की शक्ति रखते हैं।

क्या आपका ORM प्रत्येक ऑब्जेक्ट के लिए एक अलग इन्सर्ट / अपडेट करता है? यदि हाँ, तो बड़े डेटा सेट को संसाधित करते समय आपको गंभीर प्रदर्शन समस्याएँ होंगी। सेट ऑपरेशन जाने का रास्ता है। एक ORM को उन सभी संभावित सम्मिलित सेटों की सटीक रूप से मॉडलिंग करने में परेशानी होगी, जिन पर आप कार्य कर सकते हैं।

क्या आप "परत" को सर्वरों द्वारा भौतिक विभाजन या तार्किक विभाजन मानते हैं? किसी भी सर्वर पर चल रहा तर्क सैद्धांतिक रूप से अभी भी तार्किक परत के नीचे आ सकता है। आप विशेष रूप से सर्वर को विभाजित करने के बजाय अलग DLL में संकलित करके विभाजन को व्यवस्थित कर सकते हैं। यह चिंताओं के पृथक्करण को बनाए रखते हुए नाटकीय रूप से प्रतिक्रिया समय (लेकिन througput का त्याग) बढ़ा सकता है। एक विभाजन डीएलएल को बाद में थ्रूपुट (प्रतिक्रिया समय की लागत पर) बढ़ाने के लिए एक नए निर्माण के बिना अन्य सर्वरों में ले जाया जा सकता है।

Comments

डाउनवोट क्यों?

— mike30

मैंने अपमानित नहीं किया है, लेकिन कोई भी डेटाबेस सेपिस्टवादी आपको बताएगा कि डेटाबेस को तर्क मुक्त हैश मानना ​​एक बहुत ही खराब विचार है। यह डेटा अखंडता समस्याओं या प्रदर्शन समस्याओं या दोनों का कारण बनता है।

— HLGEM

@HLGEM। उत्तर डेटाबेस में तर्क रखने या डीबी सर्वर पर बैठने के कारणों का वर्णन करता है। फिर भी इसकी व्याख्या नहीं करता।

— mike30

उन्होंने काउंटरपॉइंट्स को प्राप्त नहीं किया हो सकता है जैसा कि मैंने किया था यही कारण है कि मैंने डाउनवोट नहीं किया।

— HLGEM

Answer 11

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

तो यह वास्तव में एक अच्छा डिजाइन मुहावरा या अंगूठे का नियम है। भ्रष्ट डेटा वाले सिस्टम में कोई भी प्रदर्शन मदद करने वाला नहीं है।

Answer 12

जैसा कि पहले उल्लेख किया गया है, लक्ष्य डेटाबेस से जितना संभव हो उतना कम भेजना और प्राप्त करना है क्योंकि गोल यात्राएं बहुत महंगा समय-वार हैं। बार-बार SQL मूर्तियों को भेजना विशेष रूप से अधिक जटिल प्रश्नों में समय की बर्बादी है।

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

Answer 13

याद रखने के लिए कुछ चीजें हैं:

• एक रिलेशनल डेटाबेस को विदेशी कुंजियों के माध्यम से संदर्भात्मक अखंडता सुनिश्चित करना चाहिए
• एक डेटाबेस को स्केल करना मुश्किल और महंगा हो सकता है। अधिक वेब सर्वर को जोड़कर एक वेब सर्वर को स्केल करना बहुत आसान है। अधिक SQL सर्वर पावर जोड़ने का प्रयास करें।
• C # और LINQ के साथ, आप अपने "जॉइन" कर सकते हैं और कोड के माध्यम से व्हाट्सएप कर सकते हैं ताकि आप दोनों मामलों में दुनिया के सर्वश्रेष्ठ को प्राप्त कर सकें

Answer 14

"समयपूर्व अनुकूलन सभी बुराई की जड़ है" - डोनाल्ड नुथ

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

यदि आपके पास कोई प्रदर्शन समस्याएँ हैं, तो आपको बाद में यह देखना चाहिए कि क्या कोई डेटा कैश किया जा सकता है, या क्या डेटाबेस में कोई कार्यान्वयन त्वरित होगा। सामान्य तौर पर, अतिरिक्त सर्वर या अतिरिक्त क्लाउड पावर खरीदने की लागत अतिरिक्त रखरखाव लागत और अतिरिक्त बग के प्रभाव से कम होगी।