database - यवस - संबंधपरक डेटाबेस प्रबंधन प्रणाली




एप्लिकेशन डेवलपर्स द्वारा बनाए गए डेटाबेस विकास गलतियों (20)

  1. डेटाबेस स्कीमा पर संस्करण नियंत्रण का उपयोग नहीं कर रहा है
  2. लाइव डेटाबेस के खिलाफ सीधे काम करना
  3. अधिक उन्नत डेटाबेस अवधारणाओं को पढ़ना और समझना नहीं (इंडेक्स, क्लस्टर्ड इंडेक्स, बाधाएं, भौतिक विचार, इत्यादि)
  4. स्केलेबिलिटी के लिए परीक्षण करने में विफल ... केवल 3 या 4 पंक्तियों का परीक्षण डेटा आपको वास्तविक लाइव प्रदर्शन की असली तस्वीर नहीं देगा

एप्लिकेशन डेवलपर्स द्वारा बनाई गई सामान्य डेटाबेस विकास गलतियों क्या हैं?


  1. Using an ORM to do bulk updates
  2. Selecting more data than needed. Again, typically done when using an ORM
  3. Firing sqls in a loop.
  4. Not having good test data and noticing performance degradation only on live data.

इंडेक्स का उपयोग नहीं कर रहा है।


एक "असली" डेटाबेस के बजाय एक्सेस का उपयोग करना। एसक्यूएल एक्सप्रेस , माईएसक्यूएल , और एसक्यूएलसाइट जैसे बहुत छोटे छोटे और यहां तक ​​कि मुफ्त डेटाबेस भी हैं जो काम करेंगे और बहुत बेहतर होंगे। ऐप्स को अक्सर अप्रत्याशित तरीकों से स्केल करने की आवश्यकता होती है।


तालिकाओं के बीच संबंध स्थापित करने के लिए भूलना। मुझे याद है कि जब मैंने पहली बार अपने वर्तमान नियोक्ता पर काम करना शुरू किया था तो इसे साफ करना होगा।


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


मैं जोड़ना चाहता हूं: अत्यधिक प्रदर्शन कोड पर "सुरुचिपूर्ण" कोड का अनुकूलन। कोड जो डाटाबेस के खिलाफ सबसे अच्छा काम करता है अक्सर एप्लिकेशन डेवलपर की आंखों के लिए बदसूरत होता है।

समयपूर्व अनुकूलन के बारे में बकवास विश्वास। डेटाबेस को मूल डिजाइन और किसी भी बाद के विकास में प्रदर्शन पर विचार करना चाहिए। प्रदर्शन मेरी राय में डेटाबेस डिजाइन का 50% है (40% डेटा अखंडता है और अंतिम 10% सुरक्षा है)। डेटाबेस जो नीचे से ऊपर तक नहीं बनाए जाते हैं, वे वास्तविक उपयोगकर्ताओं और वास्तविक ट्रैफ़िक को डेटाबेस के विरुद्ध रखे जाने पर बुरी तरह प्रदर्शन करेंगे। समयपूर्व अनुकूलन का कोई अनुकूलन नहीं है! इसका मतलब यह नहीं है कि आपको कोड लिखना चाहिए जो लगभग हमेशा खराब प्रदर्शन करेगा क्योंकि आपको यह आसान लगता है (उदाहरण के लिए कर्सर जिन्हें उत्पादन डेटाबेस में कभी भी अनुमति नहीं दी जानी चाहिए जब तक कि सब कुछ विफल नहीं हुआ हो)। इसका मतलब है कि आपको तब तक प्रदर्शन के आखिरी छोटे प्रदर्शन को निचोड़ने की आवश्यकता नहीं है जब तक आपको आवश्यकता न हो। डेटाबेस पर बेहतर प्रदर्शन करने के बारे में बहुत कुछ पता है, इसे डिजाइन और विकास में अनदेखा करने के लिए सबसे अच्छा दिखता है।


संग्रहित प्रक्रियाओं पर अधिक उपयोग और / या निर्भरता।

कुछ एप्लिकेशन डेवलपर्स संग्रहीत प्रक्रियाओं को मध्यम स्तर / फ्रंट एंड कोड के प्रत्यक्ष विस्तार के रूप में देखते हैं। यह माइक्रोसॉफ्ट स्टैक डेवलपर्स में एक आम विशेषता प्रतीत होता है, (मैं एक हूं, लेकिन मैं इससे बाहर निकला हूं) और कई संग्रहित प्रक्रियाएं उत्पन्न करता है जो जटिल व्यावसायिक तर्क और वर्कफ़्लो प्रोसेसिंग करते हैं। यह कहीं और बेहतर किया जाता है।

संग्रहीत प्रक्रियाएं उपयोगी होती हैं जहां यह वास्तव में सिद्ध किया गया है कि कुछ वास्तविक तकनीकी कारकों को उनके उपयोग की आवश्यकता होती है (उदाहरण के लिए, प्रदर्शन और सुरक्षा) उदाहरण के लिए, "डेटा के नजदीक" बड़े डेटा सेटों के एकत्रीकरण / फ़िल्टरिंग को बनाए रखना।

मुझे हाल ही में एक बड़े डेल्फी डेस्कटॉप एप्लिकेशन को बनाए रखने और बढ़ाने में मदद करना था, जिसमें 70% बिजनेस लॉजिक और नियम 1400 एसक्यूएल सर्वर संग्रहीत प्रक्रियाओं (यूआई इवेंट हैंडलर में शेष) में लागू किए गए थे। यह एक दुःस्वप्न था, मुख्य रूप से टीएसक्यूएल को प्रभावी इकाई परीक्षण, encapsulation और खराब उपकरण की कमी (डीबगर्स, संपादक) की कमी के difficuly के कारण।

अतीत में जावा टीम के साथ काम करना मैंने तुरंत पाया कि अक्सर उस माहौल में पूरी तरह विपरीत विपरीत होता है। एक जावा वास्तुकार ने मुझे एक बार कहा: "डेटाबेस डेटा के लिए है, कोड नहीं।"।

इन दिनों मुझे लगता है कि संग्रहित प्रो पर विचार नहीं करना एक गलती है, लेकिन इन्हें परिस्थितियों में कम से कम (डिफ़ॉल्ट रूप से नहीं) उपयोग किया जाना चाहिए जहां वे उपयोगी लाभ प्रदान करते हैं (अन्य उत्तरों देखें)।


1. उपयुक्त सूचकांक का उपयोग नहीं कर रहा है

यह अपेक्षाकृत आसान है लेकिन फिर भी यह हर समय होता है। विदेशी कुंजी पर उनके सूचकांक होना चाहिए। यदि आप किसी भी क्षेत्र में किसी फ़ील्ड का उपयोग कर रहे हैं तो आपको (शायद) पर एक इंडेक्स होना चाहिए। ऐसे इंडेक्स को अक्सर निष्पादित करने के लिए आवश्यक प्रश्नों के आधार पर कई स्तंभों को कवर करना चाहिए।

2. संदर्भित अखंडता लागू नहीं है

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

MySQL डेटाबेस पर इस विफलता को देखना आम बात है। मुझे विश्वास नहीं है कि माईसाम इसका समर्थन करता है। InnoDB करता है। आपको उन लोगों को मिल जाएगा जो MyISAM का उपयोग कर रहे हैं या जो इनो डीबी का उपयोग कर रहे हैं लेकिन वैसे भी इसका उपयोग नहीं कर रहे हैं।

यहां अधिक:

3. सरोगेट (तकनीकी) प्राथमिक कुंजी के बजाय प्राकृतिक का उपयोग करना

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

मेरी राय में आपको हमेशा सरोगेट कुंजी का उपयोग करना चाहिए। इन मुद्दों में यह मुद्दा सामने आया है:

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

याद रखें, यहां तक ​​कि देश भी अस्तित्व में रह सकते हैं (उदाहरण के लिए, युगोस्लाविया)।

4. लेखन प्रश्न जो DISTINCT को काम करने की आवश्यकता है

आप इसे ओआरएम से उत्पन्न प्रश्नों में अक्सर देखते हैं। हाइबरनेट से लॉग आउटपुट देखें और आप सभी प्रश्नों के साथ शुरू करेंगे:

SELECT DISTINCT ...

यह सुनिश्चित करने के लिए एक शॉर्टकट है कि आप डुप्लिकेट पंक्तियों को वापस नहीं करते हैं और इस प्रकार डुप्लिकेट ऑब्जेक्ट प्राप्त करते हैं। आप कभी-कभी लोगों को यह भी कर सकते हैं। यदि आप इसे बहुत अधिक देखते हैं तो यह एक वास्तविक लाल झंडा है। यह नहीं कि DISTINCT खराब है या उसके पास वैध अनुप्रयोग नहीं हैं। यह (दोनों गिनती पर) करता है लेकिन यह सही प्रश्न लिखने के लिए सरोगेट या स्टॉपगैप नहीं है।

मैं डिस्टिंट से नफरत क्यों करता हूं :

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

5. जुड़ने पर एकत्रीकरण का पक्ष लेना

डेटाबेस एप्लिकेशन डेवलपर्स द्वारा एक और आम गलती यह नहीं जानती है कि कितने महंगे एकत्रीकरण (यानी GROUP BY क्लॉज) की तुलना में तुलना में की जा सकती है।

इस बारे में आपको एक विचार देने के लिए कि यह कितना व्यापक है, मैंने इस विषय पर कई बार लिखा है और इसके लिए बहुत कुछ कम किया गया है। उदाहरण के लिए:

एसक्यूएल कथन से - "जुड़ें" बनाम "समूह द्वारा और" :

पहली क्वेरी:

SELECT userid
FROM userrole
WHERE roleid IN (1, 2, 3)
GROUP by userid
HAVING COUNT(1) = 3

प्रश्न समय: 0.312 एस

दूसरी क्वेरी:

SELECT t1.userid
FROM userrole t1
JOIN userrole t2 ON t1.userid = t2.userid AND t2.roleid = 2
JOIN userrole t3 ON t2.userid = t3.userid AND t3.roleid = 3
AND t1.roleid = 1

प्रश्न समय: 0.016 एस

ये सही है। मेरे द्वारा प्रस्तावित संस्करण संस्करण कुल संस्करण की तुलना में बीस गुना तेज है।

6. विचारों के माध्यम से जटिल प्रश्नों को सरल नहीं बनाना

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

  • पार्टी : लोग और संगठन;
  • पार्टी भूमिका : उन पार्टियों ने चीजें की, उदाहरण के लिए कर्मचारी और नियोक्ता;
  • पार्टी भूमिका संबंध : कैसे एक दूसरे से संबंधित भूमिकाएं।

उदाहरण:

  • टेड पार्टी का एक उप प्रकार है, एक व्यक्ति है;
  • टेड में कई भूमिकाएं हैं, जिनमें से एक कर्मचारी है;
  • इंटेल एक संगठन है, जो पार्टी का उप-प्रकार है;
  • इंटेल की कई भूमिकाएं हैं, जिनमें से एक नियोक्ता है;
  • इंटेल टेड को नियोजित करता है, जिसका अर्थ है कि उनकी संबंधित भूमिकाओं के बीच संबंध है।

तो टेड को अपने नियोक्ता से जोड़ने के लिए पांच टेबल शामिल हो गए हैं। आप मानते हैं कि सभी कर्मचारी व्यक्ति हैं (संगठन नहीं) और यह सहायक दृश्य प्रदान करते हैं:

CREATE VIEW vw_employee AS
SELECT p.title, p.given_names, p.surname, p.date_of_birth, p2.party_name employer_name
FROM person p
JOIN party py ON py.id = p.id
JOIN party_role child ON p.id = child.party_id
JOIN party_role_relationship prr ON child.id = prr.child_id AND prr.type = 'EMPLOYMENT'
JOIN party_role parent ON parent.id = prr.parent_id = parent.id
JOIN party p2 ON parent.party_id = p2.id

और अचानक आपके पास इच्छित डेटा का एक बहुत ही सरल दृश्य है लेकिन अत्यधिक लचीला डेटा मॉडल पर।

7. इनपुट sanitizing नहीं है

यह एक बड़ा है। अब मुझे PHP पसंद है लेकिन यदि आप नहीं जानते कि आप क्या कर रहे हैं तो हमला करने के लिए कमजोर साइटों को बनाना वास्तव में आसान है। छोटे बॉबी टेबल्स की कहानी से कुछ भी बेहतर नहीं है।

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

8. तैयार बयान का उपयोग नहीं

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

SELECT * FROM users WHERE username = 'bob'

बनाम

SELECT * FROM users WHERE username = ?

या

SELECT * FROM users WHERE username = :username

आपके मंच के आधार पर।

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

तैयार वक्तव्यों का उपयोग करने से आपको सार्थक आंकड़े भी मिलेंगे कि कितनी बार कुछ प्रश्नों का उपयोग किया जाता है।

तैयार किए गए बयान एसक्यूएल इंजेक्शन हमलों के खिलाफ भी आपकी रक्षा करेंगे।

9. पर्याप्त सामान्य नहीं है

डाटाबेस सामान्यीकरण मूल रूप से डेटाबेस डिज़ाइन को अनुकूलित करने की प्रक्रिया है या आप अपने डेटा को टेबल में कैसे व्यवस्थित करते हैं।

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

यह उपयोगकर्ता आईडी की एक सूची संग्रहीत करने के लिए सर्वश्रेष्ठ विधि में भी आया:

मैंने अन्य प्रणालियों में देखा है कि सूची एक क्रमबद्ध PHP सरणी में संग्रहीत है।

लेकिन सामान्यीकरण की कमी कई रूपों में आती है।

अधिक:

10. बहुत अधिक सामान्यीकरण

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

मैंने एक बार उस प्रणाली पर काम किया जिस पर ग्राहकों के लिए एक विशाल पदानुक्रम था जो कुछ ऐसा हुआ:

Licensee ->  Dealer Group -> Company -> Practice -> ...

इससे पहले कि आप किसी भी सार्थक डेटा प्राप्त करने से पहले आपको लगभग 11 तालिकाओं में शामिल होना पड़े। यह बहुत दूर ले जाने वाले सामान्यीकरण का एक अच्छा उदाहरण था।

बिंदु पर अधिक, सावधान और माना जाता है कि denormalization के लिए भारी प्रदर्शन लाभ हो सकता है लेकिन यह करने के दौरान आपको वास्तव में सावधान रहना होगा।

अधिक:

11. विशेष आर्क का उपयोग करना

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

एक व्यावहारिक गाइड से संबंधपरक डेटाबेस डिजाइन से :

जहां भी संभव हो, हमने विशेष आर्क निर्माण के खिलाफ दृढ़ता से सलाह दी है, अच्छे कारण के लिए कि वे कोड लिखने के लिए अजीब हो सकते हैं और अधिक रखरखाव की कठिनाइयों का सामना कर सकते हैं।

12. प्रश्नों पर प्रदर्शन विश्लेषण नहीं कर रहे हैं

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

13. यूनियन और विशेष रूप से यूनियन संरचनाओं पर यूनियन पर अधिक निर्भरता

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

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

यूनियन, विशेष रूप से जब जॉइन या आश्रित उपक्विरी में उपयोग किया जाता है, तो डेटाबेस को अपंग कर सकता है। जब भी संभव हो उन्हें टालने का प्रयास करें।

14. प्रश्नों में या शर्तों का उपयोग करना

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

खराब:

... WHERE a = 2 OR a = 5 OR a = 11

बेहतर:

... WHERE a IN (2, 5, 11)

अब आपका एसक्यूएल ऑप्टिमाइज़र प्रभावी रूप से दूसरी क्वेरी को दूसरे में बदल सकता है। लेकिन ऐसा नहीं हो सकता है। बस यह मत करो।

15. अपने डेटा मॉडल को उच्च प्रदर्शन करने वाले समाधानों में उधार देने के लिए डिज़ाइन नहीं करना

यह मापने के लिए एक कठिन बिंदु है। यह आमतौर पर इसके प्रभाव से मनाया जाता है। यदि आप अपेक्षाकृत सरल कार्यों के लिए खुद को ग्रेनरी क्वेरी लिखते हैं या अपेक्षाकृत सीधी जानकारी खोजने के लिए प्रश्न प्रभावी नहीं हैं, तो आपके पास शायद एक खराब डेटा मॉडल हो।

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

सभी बुराईयो की जड़ समयपूर्व इष्टतमीकरण है

16. डेटाबेस लेनदेन का गलत उपयोग

एक विशिष्ट प्रक्रिया के लिए सभी डेटा परिवर्तन परमाणु होना चाहिए। अगर ऑपरेशन सफल होता है, तो यह पूरी तरह से करता है। यदि यह विफल रहता है, तो डेटा अपरिवर्तित छोड़ दिया जाता है। - 'आधे से किए गए' परिवर्तनों की कोई संभावना नहीं होनी चाहिए।

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

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

  • पहले बयान से पहले एक लेनदेन शुरू करें।
  • अंतिम वक्तव्य के बाद लेनदेन प्रतिबद्ध करें।
  • किसी भी त्रुटि पर, लेनदेन रोलबैक। और बहुत एनबी! त्रुटि के बाद अनुसरण करने वाले सभी बयानों को छोड़ना / रद्द करना न भूलें।

आपकी डेटाबेस कनेक्टिविटी परत के तरीके के बारे में सावधानीपूर्वक ध्यान देने की भी सिफारिश की जाती है, और डेटाबेस इंजन इस संबंध में बातचीत करता है।

17. 'सेट-आधारित' प्रतिमान को समझना नहीं

एसक्यूएल भाषा विशिष्ट प्रकार की समस्याओं के लिए उपयुक्त एक विशिष्ट प्रतिमान का पालन करती है। विभिन्न विक्रेताओं-विशिष्ट एक्सटेंशन के बावजूद, भाषा जावा, सी #, डेल्फी इत्यादि जैसी कठिनाइयों में तुच्छ समस्याओं से निपटने के लिए संघर्ष करती है।

समझ की कमी कुछ तरीकों से खुद को प्रकट करती है।

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

जिम्मेदारी के स्पष्ट विभाजन का निर्धारण करें, और प्रत्येक समस्या को हल करने के लिए उचित उपकरण का उपयोग करने का प्रयास करें।


Not understanding how a DBMS works under the hood.

You cannot properly drive a stick without understanding how a clutch works. And you cannot understand how to use a Database without understanding that you are really just writing to a file on your hard disk.

Specifically:

  1. Do you know what a Clustered Index is? Did you think about it when you designed your schema?

  2. Do you know how to use indexes properly? How to reuse an index? Do you know what a Covering Index is?

  3. So great, you have indexes. How big is 1 row in your index? How big will the index be when you have a lot of data? Will that fit easily into memory? If it won't it's useless as an index.

  4. Have you ever used EXPLAIN in MySQL? Great. Now be honest with yourself: Did you understand even half of what you saw? No, you probably didn't. Fix that.

  5. Do you understand the Query Cache? Do you know what makes a query un-cachable?

  6. Are you using MyISAM? If you NEED full text search, MyISAM's is crap anyway. Use Sphinx. Then switch to Inno.


सहसंबंधित सबक्वायरीज़ के कारण खराब प्रदर्शन

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

प्रदूषित उदाहरण और ओरेकल सिंटैक्स को क्षमा करें, लेकिन मान लीजिए कि आप अपने सभी स्टोरों में किराए पर ले चुके सभी कर्मचारियों को ढूंढना चाहते थे क्योंकि आखिरी बार स्टोर ने 10,000 डॉलर से कम बिक्री की थी।

select e.first_name, e.last_name
from employee e
where e.start_date > 
        (select max(ds.transaction_date)
         from daily_sales ds
         where ds.store_id = e.store_id and
               ds.total < 10000)

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

select e.first_name, e.last_name
from employee e,
     (select ds.store_id,
             max(s.transaction_date) transaction_date
      from daily_sales ds
      where ds.total < 10000
      group by s.store_id) dsx
where e.store_id = dsx.store_id and
      e.start_date > dsx.transaction_date

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

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


For SQL-based databases:

  1. Not taking advantage of CLUSTERED INDEXES or choosing the wrong column(s) to CLUSTER.
  2. Not using a SERIAL (autonumber) datatype as a PRIMARY KEY to join to a FOREIGN KEY (INT) in a parent/child table relationship.
  3. Not UPDATING STATISTICS on a table when many records have been INSERTED or DELETED.
  4. Not reorganizing (ie unloading, droping, re-creating, loading and re-indexing) tables when many rows have been inserted or deleted (some engines physically keep deleted rows in a table with a delete flag.)
  5. Not taking advantage of FRAGMENT ON EXPRESSION (if supported) on large tables which have high transaction rates.
  6. Choosing the wrong datatype for a column!
  7. Not choosing a proper column name.
  8. Not adding new columns at the end of the table.
  9. Not creating proper indexes to support frequently used queries.
  10. creating indexes on columns with few possible values and creating unnecessary indexes.
    ...more to be added.

I hate it when developers use nested select statements or even functions the return the result of a select statement inside the "SELECT" portion of a query.

I'm actually surprised I don't see this anywhere else here, perhaps I overlooked it, although @adam has a similar issue indicated.

उदाहरण:

SELECT
    (SELECT TOP 1 SomeValue FROM SomeTable WHERE SomeDate = c.Date ORDER BY SomeValue desc) As FirstVal
    ,(SELECT OtherValue FROM SomeOtherTable WHERE SomeOtherCriteria = c.Criteria) As SecondVal
FROM
    MyTable c

In this scenario, if MyTable returns 10000 rows the result is as if the query just ran 20001 queries, since it had to run the initial query plus query each of the other tables once for each line of result.

Developers can get away with this working in a development environment where they are only returning a few rows of data and the sub tables usually only have a small amount of data, but in a production environment, this kind of query can become exponentially costly as more data is added to the tables.

A better (not necessarily perfect) example would be something like:

SELECT
     s.SomeValue As FirstVal
    ,o.OtherValue As SecondVal
FROM
    MyTable c
    LEFT JOIN (
        SELECT SomeDate, MAX(SomeValue) as SomeValue
        FROM SomeTable 
        GROUP BY SomeDate
     ) s ON c.Date = s.SomeDate
    LEFT JOIN SomeOtherTable o ON c.Criteria = o.SomeOtherCriteria

This allows database optimizers to shuffle the data together, rather than requery on each record from the main table and I usually find when I have to fix code where this problem has been created, I usually end up increasing the speed of queries by 100% or more while simultaneously reducing CPU and memory usage.


Not doing the correct level of normalization . You want to make sure that data is not duplicated, and that you are splitting data into different as needed. You also need to make sure you are not following normalization too far as that will hurt performance.


Not having an understanding of the databases concurrency model and how this affects development. It's easy to add indexes and tweak queries after the fact. However applications designed without proper consideration for hotspots, resource contention and correct operation (Assuming what you just read is still valid!) can require significant changes within the database and application tier to correct later.


Not paying enough attention towards managing database connections in your application. Then you find out the application, the computer, the server, and the network is clogged.


The most common mistake I've seen in twenty years: not planning ahead. Many developers will create a database, and tables, and then continually modify and expand the tables as they build out the applications. The end result is often a mess and inefficient and difficult to clean up or simplify later on.


This has been said before, but: indexes, indexes, indexes . I've seen so many cases of poorly performing enterprise web apps that were fixed by simply doing a little profiling (to see which tables were being hit a lot), and then adding an index on those tables. This doesn't even require much in the way of SQL writing knowledge, and the payoff is huge.

Avoid data duplication like the plague. Some people advocate that a little duplication won't hurt, and will improve performance. Hey, I'm not saying that you have to torture your schema into Third Normal Form, until it's so abstract that not even the DBA's know what's going on. Just understand that whenever you duplicate a set of names, or zipcodes, or shipping codes, the copies WILL fall out of synch with each other eventually. It WILL happen. And then you'll be kicking yourself as you run the weekly maintenance script.

And lastly: use a clear, consistent, intuitive naming convention. In the same way that a well written piece of code should be readable, a good SQL schema or query should be readable and practically tell you what it's doing, even without comments. You'll thank yourself in six months, when you have to to maintenance on the tables. "SELECT account_number, billing_date FROM national_accounts" is infinitely easier to work with than "SELECT ACCNTNBR, BILLDAT FROM NTNLACCTS".


a) Hardcoding query values in string
b) Putting the database query code in the "OnButtonPress" action in a Windows Forms application

I have seen both.


  • Dismissing an ORM like Hibernate out of hand, for reasons like "it's too magical" or "not on my database".
  • Relying too heavily on an ORM like Hibernate and trying to shoehorn it in where it isn't appropriate.




database-design