पता सबसे आसान फ़ील्ड लगता है और असल में सबसे कठिन है। एक ऐसा फ़ॉर्म जो एक देश के लिए बनाया गया हो, वह दूसरे देश के डेटा पर चुपचाप गलत व्यवहार करने लगता है। कुछ फ़ील्ड जो एक जगह अनिवार्य हैं, दूसरी जगह अस्तित्व में ही नहीं होते। कुछ जगह संख्या का क्रम ऊपर से नीचे चलता है और कुछ जगह नीचे से ऊपर। यह विविधता कोई अपवाद नहीं है, यही सामान्य स्थिति है।
यह लेख बताता है कि देशों के बीच पता प्रारूप असल में किन-किन बिंदुओं पर टकराता है, कौन सी गलतियां देखने में नहीं आतीं पर सत्यापन में सीधे पकड़ में आती हैं, और ऐसा बहु-देशीय मॉडल कैसे बनाया जाए जो हर देश की अपनी परंपरा को तोड़े बिना काम करे।
तत्वों का क्रम देश के अनुसार कैसे बदलता है?
ज्यादातर यूरोपीय और उत्तरी अमेरिकी परंपरा में पता छोटे से बड़े की ओर लिखा जाता है। पहले भवन संख्या और सड़क, फिर इलाका, फिर शहर, फिर प्रांत, और सबसे आखिर में देश। जापान की परंपरा बिल्कुल उलटी है। वहां सबसे बड़ा हिस्सा पहले आता है और सबसे छोटा सबसे आखिर में, इसलिए पढ़ने का क्रम वही जानता है जो उस परंपरा में पला हो। जो सिस्टम यह मान लेता है कि क्रम हर जगह एक ही है, वह जापानी पते को उलटा पढ़ेगा और गलत शहर पर पहुंचाएगा।
इन दो छोरों के बीच कई देश बैठते हैं। तुर्की और लैटिन अमेरिका के कई देशों में क्रम इन दोनों के बीच का है — पहले भवन, फिर इलाका, फिर शहर। जर्मन भाषी देशों में डाक कोड शहर के नाम से पहले आता है, और उसी तरह की परंपरा कुछ और यूरोपीय देशों में भी मिलती है। यह छोटा-सा अंतर ऐसी प्रणालियों में बड़ी गड़बड़ी पैदा करता है जो डाक कोड को हमेशा शहर के बाद जोड़कर लिखती हैं।
इससे एक साफ अभियांत्रिकी नियम निकलता है — दिखाने का क्रम और भंडारण का क्रम अलग-अलग रखें। डेटा को हमेशा ऐसी संरचना में रखें जहां हर हिस्सा अपना अलग फ़ील्ड हो, और लिखने का क्रम बाद में तय करें। जो प्रणाली पता को पहले से जोड़कर एक पंक्ति में बना लेती है, वह बाद में क्रम नहीं बदल सकती, क्योंकि अब उसके पास हिस्से अलग नहीं हैं, केवल एक लंबी डोरी है।
अलग-अलग देशों में डाक कोड कैसा दिखता है
डाक कोड की लंबाई और ढांचा हर देश में अलग है। कई देशों में यह पांच अंकों का होता है, और इनमें कुछ ऐसे भी हैं जहां पहला अंक क्षेत्र बताता है। इसका एक बहुत मूर्खतापूर्ण परिणाम होता है जिसे बहुत कम लोग पहचानते हैं — अगर आप इस फ़ील्ड को संख्यात्मक स्तंभ में रखेंगे, तो शुरू के शून्य गायब हो जाएंगे। पता वैसा दिखेगा जैसा चलता है, पर वह गलत डाक क्षेत्र को दर्शाएगा। इसलिए डाक कोड को हमेशा पाठ के रूप में भंडारित करना चाहिए, संख्या के रूप में कभी नहीं।
कुछ देशों में डाक कोड केवल अंकों का नहीं होता। ब्रिटेन में यह अक्षरों और अंकों का मिश्रण होता है, लंबाई एक जैसी नहीं होती, और उसमें बीच में एक जगह भी होती है जो अर्थ रखती है। ऊपरी और निचले अक्षरों का भी महत्व होता है, इसलिए छोटे-बड़े अक्षरों को एक कर देने वाली प्रणाली यहां गलती करती है। कनाडा में डाक कोड अक्षर और अंक बारी-बारी से आते हैं, जिससे एक ऐसा ढांचा बनता है जिसे जांचा जा सकता है। नीदरलैंड में पहले चार अंक और फिर दो अक्षर आते हैं, और यह जोड़ी दोनों को साथ रखकर ही अर्थ रखती है।
कुछ देश डाक कोड के भीतर विराम चिह्न जोड़ते हैं। पोलैंड में पांच अंकों के बाद दूसरे अंक के बाद एक जुड़ाव चिह्न आता है। जापान में सात अंकों के बाद पहले तीन अंकों के बाद ऐसा ही चिह्न आता है। ब्राजील में आठ अंकों के बाद पहले पांच अंकों के बाद यह चिह्न आता है। यहां सबसे आम गलती यह है कि फ़ॉर्म इन चिह्न को अनिवार्य मान लेता है, जबकि उपयोगकर्ता उन्हें छोड़ देता है, और फिर वैध डाक कोड अवैध घोषित हो जाता है।
आयरलैंड जैसे देशों में अलग व्यवस्था है जिसमें क्षेत्रीय पहचान का अपना तरीका है, और कुछ देशों में डाक कोड होता ही नहीं। यह आखिरी बात बहुत लोगों को चौंकाती है। ऐसे देश के लिए बने फ़ॉर्म में डाक कोड को अनिवार्य रखना सीधा विरोधाभास है, और उसे भरने का दबाव उपयोगकर्ता को कुछ भी लिखने पर मजबूर करता है — जिससे डेटा में ऐसी संख्या आ जाती है जिसका कोई अर्थ नहीं।
यही बात घर के नंबर पर भी लागू होती है। कई देशों में यह केवल अंक नहीं, बल्कि अक्षरों के साथ मिला हुआ होता है। इसे संख्यात्मक फ़ील्ड में रखना ऐसी गलती है जो कभी शोर नहीं करती पर हमेशा डेटा खराब करती है। जहां डाक कोड को पाठ के रूप में रखना जरूरी है, वहीं घर के नंबर के लिए भी यही नियम अपनाना चाहिए।
कौन से फ़ील्ड कुछ देशों में होते हैं और कुछ में नहीं
प्रशासनिक स्तर का मामला देशों के बीच सबसे बड़ा और सबसे अनदेखा अंतर है। किसी देश में शहर के नीचे एक स्तर होता है, किसी में दो। तुर्की में एक स्तर और फिर मोहल्ले का स्तर आता है। जापान में शहर और उसके अंदर वार्ड या ब्लॉक की अलग व्यवस्था होती है। लैटिन अमेरिका के कई देशों में बस्ती या इलाके का अपना नाम होता है जो पते का अनिवार्य हिस्सा है। इंडोनेशिया में गांव और उसके भीतर के स्तर का अपना ढांचा है। जो सिस्टम इन सबको एक ही ढांचे में ठूंसने की कोशिश करता है, वह हर देश में कुछ न कुछ खो देता है।
राज्य या प्रांत का फ़ील्ड इसका सबसे साफ उदाहरण है। संयुक्त राज्य, ऑस्ट्रेलिया और कनाडा जैसे देशों में यह अनिवार्य है और उसके मान्य मान भी तय हैं। बहुत से देशों में यह पूरी तरह वैकल्पिक है, और कुछ में तो ऐसी संरचना ही नहीं होती जिसे राज्य कहा जा सके। अगर आपका फ़ॉर्म इस फ़ील्ड को हर जगह अनिवार्य रखता है, तो जिन देशों में यह नहीं है वहां उपयोगकर्ता कुछ भी लिख देगा, और आपके डेटा में ऐसी राज्य की पंक्तियां आ जाएंगी जो वास्तव में कुछ नहीं हैं।
इसका ईमानदार समाधान एक ही फ़ॉर्म रखना और उसके साथ प्रति देश एक कॉन्फ़िगरेशन रखना है। उस कॉन्फ़िगरेशन में यह दर्ज होना चाहिए कि कौन सा फ़ील्ड उस देश में अनिवार्य है, कौन सा वैकल्पिक है, और कौन सा वहां होता ही नहीं। यह कॉन्फ़िगरेशन अपने आप में डेटा है, और इसे भी उसी गंभीरता से परखा जाना चाहिए जैसे बाकी सिस्टम को। बहुत सी टीमें इसे कभी नहीं जांचतीं और फिर आश्चर्य करती हैं कि कुछ देशों के फ़ॉर्म क्यों कभी पूरे नहीं भर पाते।
पता पंक्ति का समझौता क्या है और उसकी कीमत कितनी है?
दुनिया भर के पतों को संभालने का सबसे आसान रास्ता यह है कि सबको दो या तीन सामान्य पंक्तियों में समेट दिया जाए, और उसके बाद अलग से शहर, क्षेत्र और डाक कोड मांगा जाए। इसका एक बहुत ठोस फायदा है — यह कभी किसी को रोकता नहीं। किसी भी देश का उपयोगकर्ता अपना पता इन पंक्तियों में किसी तरह लिख ही देगा, और फ़ॉर्म आगे बढ़ जाएगा। जहां कंपनी को जल्दी काम चलाना हो, यह रास्ता बुरा नहीं लगता।
पर इसकी कीमत बाद में चुकाई जाती है। पहली समस्या यह है कि संरचित जानकारी असंरचित पाठ बन जाती है। भवन संख्या, सड़क, मोहल्ला और इलाका सब एक ही डोरी में घुल जाते हैं, और बाद में उन्हें अलग करने के लिए अनुमान लगाना पड़ता है। दूसरी समस्या यह है कि जब हर देश का पता एक ही खाली पंक्ति में जाता है, तो आपके पास यह तय करने का कोई तरीका नहीं बचता कि कौन सा हिस्सा क्या है।
तीसरी समस्या नीचे की प्रक्रियाओं में दिखती है। जब आपको दो पतों को मिलाना हो, या यह देखना हो कि एक ही इमारत के दो रिकॉर्ड एक हैं या नहीं, तो पाठ के रूप में पड़े पते की तुलना करना लगभग बेकार होता है। छोटे-बड़े अक्षर, अतिरिक्त जगह, अलग वर्तनी — हर फर्क एक नया रिकॉर्ड बना देता है। यह समस्या धीरे-धीरे बढ़ती है और बाद में उसे ठीक करना बहुत महंगा पड़ता है।
चौथी और सबसे खतरनाक समस्या यह है कि ऐसी प्रणाली विफलता पर सफलता दिखाती है। अगर डाक कोड गायब है या वह गलत देश का है, तो भी फ़ॉर्म पास हो जाता है और सिस्टम संतुष्ट दिखता है। यहां असली नुकसान तुरंत नहीं दिखता। वह तब दिखता है जब किसी रिपोर्ट में गिनती नहीं मिलती, या जब किसी शिपिंग या कर की गणना गलत देयता निकालती है।
बहु-देशीय पता मॉडल कैसे बनाया जाए
पहला सिद्धांत यह है कि देश का फ़ील्ड सब कुछ चलाता है। उसे सबसे पहले लिया जाए, और उसके बाद ही बाकी सब कुछ तय हो। जो फ़ॉर्म देश को आखिर में पूछता है, वह अपनी ही सुसंगति तोड़ता है क्योंकि तब तक उपयोगकर्ता ने ऐसे फ़ील्ड भर दिए होते हैं जो उस देश के लिए थे ही नहीं। इसलिए देश का चुनाव सबसे ऊपर रखें, और उसके बाद की हर चीज को उस पर निर्भर बनाएं।
दूसरा सिद्धांत यह है कि डाक कोड को पहले सामान्य करें, फिर जांचें। सामान्य करने का क्रम हर देश में अलग होगा — कहीं जगह हटानी है, कहीं जोड़नी है, कहीं अक्षरों का आकार बदलना है। किसी भी हालत में शुरू के शून्य नहीं हटाने चाहिए। जो प्रणाली सामान्य करने और जांचने को एक ही कदम में कर देती है, वह कभी यह नहीं बता पाती कि समस्या डेटा में थी या उसके अपने नियम में।
तीसरा सिद्धांत यह है कि प्रशासनिक स्तरों को सपाट स्तंभों में नहीं, बल्कि आमने-सामने जुड़े ढांचे में रखें। हर देश का अपना स्तर-क्रम होता है, और उस क्रम को डेटा के रूप में व्यक्त किया जा सकता है। जब आप ऐसा करते हैं, तो नया देश जोड़ना कोड बदलने का काम नहीं रह जाता, केवल डेटा जोड़ने का काम रह जाता है।
चौथा सिद्धांत यह है कि परीक्षण देश के हिसाब से हो, फ़ील्ड के हिसाब से नहीं। यह बारीक पर बहुत असरदार फर्क है। अगर आप हर फ़ील्ड को अलग-अलग परखेंगे, तो आप कभी वह मामला नहीं पकड़ेंगे जहां दो फ़ील्ड अलग-अलग ठीक हैं पर मिलकर गलत हैं। जो चीज असल में टूटती है, वह हमेशा फ़ील्डों के बीच का संबंध होता है।
पांचवां, हर नियम के पीछे उसका स्रोत दर्ज करें। यह बात सुनने में फालतू लगती है जब तक कि किसी देश का डाक कोड न बदल जाए और आपको यह तय न करना पड़े कि किस नियम को अपडेट करना है। जिस टीम के पास यह दर्ज नहीं होता कि कोई नियम कहां से आया, वह हर बदलाव पर अनुमान लगाती है। इसके साथ ही फ़ोन को पते से अलग मत देखें, क्योंकि देश का कोड और क्षेत्रीय उपक्रम दोनों एक ही स्रोत से आने चाहिए और दोनों में एक ही तरह की असंगति हो सकती है।
देश-सजग टेस्ट डेटासेट के लिए क्या जरूरी है
सबसे पहली जरूरत यह है कि डेटासेट में हर देश के लिए अलग नियम हों, एक वैश्विक नियम न हो। वैश्विक नियम सुविधाजनक लगता है पर वह हमेशा किसी न किसी देश को तोड़ता है, और वह देश अक्सर वही होता है जिसका कारोबार सबसे कम है और इसलिए सबसे कम परखा गया है। इस डेटासेट को बनाए रखना भी उतना ही जरूरी है जितना उसे बनाना, क्योंकि डाक व्यवस्थाएं समय के साथ बदलती हैं।
दूसरी जरूरत यह है कि हर नियम के साथ उसका स्रोत जुड़ा हो। किसी ऐसे डेटासेट से बचें जिसमें संख्याएं तो हैं पर यह पता नहीं कि वे कहां से आईं। जब वह स्रोत बदलेगा, तब आपके पास यह तय करने का आधार होना चाहिए कि कौन सा हिस्सा पुराना पड़ गया है। ऐसे डेटासेट की गुणवत्ता समय के साथ गिरती है जिसे अपडेट करने का कोई रास्ता न हो।
तीसरी और सबसे महत्वपूर्ण जरूरत यह है कि डेटा के साथ उसकी सीमाएं भी लिखी हों। अगर आपका डेटासेट काल्पनिक पते बनाता है, तो यह बात डेटासेट के भीतर ही दर्ज होनी चाहिए, केवल किसी अलग दस्तावेज में नहीं। कोई भी व्यक्ति जो उस डेटा को उठाए, यह जान सके कि उसका उपयोग असली डिलीवरी के लिए नहीं किया जा सकता।
साथ ही यह भी साफ होना चाहिए कि यह डेटा किसी निवास का प्रमाण नहीं है, किसी व्यक्ति की पहचान सिद्ध नहीं करता, और किसी खाते या सेवा को खोलने के लिए मान्य दस्तावेज नहीं है। ये सीमाएं इसलिए जरूरी हैं क्योंकि बनाया गया रिकॉर्ड देखने में इतना विश्वसनीय होता है कि वह असली लगने लगता है, और उस भ्रम की कीमत इस प्रोजेक्ट से बाहर चुकाई जाती है।
शुरुआत करने के लिए पता टूल का उपयोग करें और उसके साथ देश के नियम जोड़ें। जब आप हर देश के लिए अलग फिक्स्चर रखने लगते हैं, तो जल्दी ही यह पता चलता है कि कौन सा नियम कहां तोड़ रहा है। इसके साथ सत्यापन के नियम और पहचान के फ़ील्ड भी जोड़ें, क्योंकि असली प्रणालियों में पता, फ़ोन और पहचान हमेशा एक साथ चलते हैं और एक में की गई गलती दूसरे में दिखती है।