सहायता से संपर्क करें

हम ईमेल से जवाब देते हैं, आम तौर पर दो दिन के अंदर।

Google reCAPTCHA दुरुपयोग से बचाव के लिए इस सबमिशन की जाँच करता है; इसके लिए डेटा Google को भेजा जाता है। स्क्रिप्ट तभी लोड होती है, जब यह फ़ॉर्म खोला जाता है।

← सभी पोस्ट

Stats4U 2 से बचे तीन कॉलम

यहाँ की मुख्य काउंटर टेबल में 1,66,436 पंक्तियाँ हैं और कई ऐसे कॉलम हैं जो ज़रूरी लगते हैं। उनमें से तीन हैं lastdomain, firstdomain और userdomain। इनमें डेटा है:

lastdomain15,525 पंक्तियों में भरा
firstdomain15,457 पंक्तियों में भरा
userdomain2,982 पंक्तियों में भरा
काउंटर पंक्तियाँ: 1,66,436lastdomain15,525firstdomain15,457userdomain2,9821,66,436

इन्हें कुछ भी नहीं लिखता। कोडबेस में कहीं भी कोई स्टेटमेंट इन तीनों में से किसी को सेट नहीं करता। ये मान इस सेवा की पिछली पीढ़ी के हैं, उसी हाल में जमे हुए जिसमें वे उसके बंद होने के समय थे, और तब से बनी हर पंक्ति में ये खाली हैं।

आधा भरा कॉलम खाली कॉलम से ज़्यादा क्यों उलझाता है

पूरी तरह खाली कॉलम साफ़ तौर पर मृत है। उस पर कोई कुछ नहीं बनाता, उससे कोई रिपोर्ट नहीं निकालता, कोई पूरी दोपहर यह सोचते हुए नहीं बिताता कि इसका मतलब क्या है।

जो कॉलम 9% पंक्तियों में भरा हो, वह एक जाल है। वह ऐसे फ़ील्ड जैसा दिखता है जो कभी भरा जाता है और कभी नहीं — और किसी कॉलम के लिए यह बिल्कुल आम बात है। जिसे भी यह मिलता है, वह स्वाभाविक रूप से मान लेता है कि कोई नियम तय करता होगा कि यह कब भरा जाता है, और उस नियम को खोजने लगता है। ऐसा कोई नियम है ही नहीं।

और ये पुराने मान निष्क्रिय पंक्तियों में कहीं छिपे नहीं हैं, जहाँ वे कोई नुकसान न कर सकें। जिन पंक्तियों में यह कॉलम भरा है, यानी lastdomain, उनमें से 1,613 ऐसे काउंटरों की हैं जो इस साल भी अपडेट हो रहे थे। दस साल पहले दर्ज डोमेन वाला कोई सक्रिय काउंटर बिल्कुल वैसा ही दिखता है जैसा मौजूदा डोमेन वाला सक्रिय काउंटर।

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

जल्दी कैसे पहचानें

नाम के लिए नहीं, लिखने वाले स्टेटमेंट के लिए grep करें। कॉलम का नाम SELECT सूचियों में, स्कीमा डंप में, पुराने माइग्रेशन में, टिप्पणियों में आता है — और इनमें से कुछ भी कुछ साबित नहीं करता। फ़ैसला इस बात से होता है कि कोई INSERT या UPDATE उसका ज़िक्र करता है या नहीं। यह खोज एक मिनट लेती है और इस तरह निर्णायक है, जैसे कोड के आसपास पढ़ना कभी नहीं होता।

दूसरी जाँच खुद डेटा है: अगर मान वाली सबसे नई पंक्ति सालों पुरानी है, तो कॉलम एक जीवाश्म है, कोड चाहे जो भी कहता दिखे।

वे अब भी वहाँ क्यों हैं

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

इसलिए इसके बजाय इन्हें दर्ज किया गया है। यह टिप्पणी रखने की कोई स्पष्ट जगह नहीं है — इस डेटाबेस का स्कीमा सिर्फ़ चलते हुए डेटाबेस में मौजूद है, रिपॉज़िटरी की किसी फ़ाइल में नहीं — इसलिए वह वहाँ गई जहाँ कोई सच में उससे टकराएगा: उस क्लास में जो काउंटर की पंक्ति पढ़ती है, ठीक वहीं जहाँ ये कॉलम सामने से गुज़रते हैं। ऐसी फ़ाइल में लिखी टिप्पणी, जिसे कोई नहीं खोलता, दस्तावेज़ नहीं है। वह किसी जाल को फ़ुटनोट में तभी बदलती है, जब वह रास्ते पर हो।

विज्ञापन