2010-11-23 13 views
7

मुझे एक बहुत ही खराब कोड वाली ई-कॉमर्स साइट को बनाए रखने का कार्य विरासत में मिला है और मैं बहुत सारे कोड को पुन: सक्रिय करने और चल रही बग को ठीक करने की कोशिश कर रहा हूं।क्या डेटाबेस कारण के लिए किसी इंडेक्स पर auto_increment का उपयोग करने का कोई कारण नहीं है?

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

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

उत्तर

8

मैंने इसे किसी ऐसे व्यक्ति से पहले देखा है जो उस सुविधा को नहीं जानता था। निश्चित रूप से ऑटो-वृद्धि सुविधा का उपयोग करें।

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

+2

मैं एक बार सी # में रिवर्सबोलियन नामक एक समारोह में आया था। यह सब एक बूलियन को एक पैरामीटर के रूप में स्वीकार किया गया था और परिणामस्वरूप रिवर्स वापस कर दिया गया था। यह अत्यधिक जटिल था और सिर्फ सादा गूंगा था। सब क्योंकि डेवलपर ऑपरेटर से अनजान था। – theChrisKent

+2

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

+0

डब्ल्यूटीएफ एफटीडब्ल्यू! जो कुछ मैंने सोचा था ... बस देखना चाहता था कि मुझे कुछ याद आ रहा है, या अगर इस समारोह के लिए कुछ छुपा कारण था। – goldenapples

5

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

1

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

इस कारण से, मैंने डेटा को स्थानांतरित करने में आसानी के लिए अनुक्रमिक गइड्स का उपयोग अपनी प्राथमिक कुंजी के रूप में किया है, लेकिन आईडी को पॉप्युलेट करने के लिए पंक्तियों की गणना करना WTF का थोड़ा सा है।

0

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

1

संभवतः ऐतिहासिक कारणों से ऐसा किया गया था; यानी पिछले संस्करणों में ऑटोइनक चर नहीं थे। मैंने कोड लिखा है जो डेटाबेस पर मैन्युअल ऑटोइनक फ़ील्ड का उपयोग करता है जो ऑटोइनक प्रकारों का समर्थन नहीं करता है, लेकिन मेरा कोड गिनती() को खींचने के रूप में काफी अक्षम नहीं था।

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

3

एकमात्र मुद्दा मुझे आंशिक रूप से उचित पाया गया (लेकिन पूरी तरह से टालने योग्य!) auto_inc फ़ील्ड के विरुद्ध यह है कि डिफ़ॉल्ट रूप से कुछ बैकअप टूल में auto_inc मानों को तालिका परिभाषा में शामिल किया गया है, भले ही आप डेटा को डीबी डंप में शामिल न करें जो असुविधाजनक हो।

3

विशिष्ट स्थिति के आधार पर, प्राथमिक कुंजी के रूप में लगातार संख्याओं का उपयोग न करने के लिए स्पष्ट रूप से कई कारण हैं।

:

हालांकि, के तहत दिए गए है कि मुझे क्या करना के लिए देखना चाहते हैं लगातार नंबर एक प्राथमिक कुंजी के रूप में, मैं auto_increment कार्यक्षमता MySQL में बनाया का उपयोग नहीं करने का कोई कारण नहीं देखते हैं प्रदान करता है

1

दो बातें 1. आपके आरडीबीएमएस बुद्धिमानी से पुनरारंभ करने पर ऑटो-वृद्धि मूल्य सेट करते हैं। जब भी सर्वर पुनरारंभ होता है तो हमारे इंजीनियरों 100000s के ऑर्डर द्वारा ऑटो-इंक्रिमेंटमेंट फील्ड कूदने के लिए अपनी स्वयं की ऑटो-वृद्धि कुंजी को घुमा रहे थे। हालांकि, किसी बिंदु पर साइबेस ने ऑटो-वृद्धि के आकार को सेट करने के लिए एक विकल्प जोड़ा।

2. दूसरी जगह जहां ऑटो-वृद्धि खराब हो सकती है, यदि आप डेटाबेस को दोहरा रहे हैं और मास्टर-मास्टर कॉन्फ़िगरेशन का उपयोग कर रहे हैं। यदि आप दोनों डेटाबेस (ADWSEDD) पर लिखते हैं, तो आप पहचान-टक्कर में भाग सकते हैं।

मुझे संदेह है कि इनमें से कोई भी मामला था, लेकिन चीजों के बारे में पता होना चाहिए।

संबंधित मुद्दे

 संबंधित मुद्दे