मेरे वर्तमान ऐप को उपयोगकर्ता के लिए पता जानकारी स्टोर करने की आवश्यकता है। मैं वर्तमान में इस बात पर बहस कर रहा हूं कि पारंपरिक सड़क पता/शहर/राज्य/ज़िप टेक्स्टबॉक्स और ड्रॉपडाउन का उपयोग करना है या केवल एक पंक्ति पर सबकुछ रखने की Google की विधि के साथ जाना है। इन शिष्टाचार में से किसी एक में पता जानकारी संग्रहीत करने के पेशेवरों/विपक्ष पर कोई विचार?क्या आप सड़क/शहर/राज्य/ज़िप में पते तोड़ते हैं?
आपको इसे विभाजित करना चाहिए। इससे सड़क पर रिपोर्ट करना बहुत आसान हो जाएगा। क्या होता है यदि आप किसी राज्य या ज़िप कोड या शहर के सभी निवासियों को खींचना चाहते हैं? यदि आप सभी एक फ़ील्ड का उपयोग करते हैं, तो आप फंस जाएंगे और चाहते हैं कि आपने इसे विभाजित कर दिया हो।
इसके अलावा, यदि आप उन्हें इसके लिए संकेत नहीं देते हैं तो उपयोगकर्ता आपको आवश्यक सभी जानकारी डालना भूल जाएंगे।
अपनी पोस्ट पर उपयोगकर्ता के इनपुट टैग द्वारा परखने के बाद, मैं तुम्हें उपयोगकर्ता डेटा में प्रवेश करती है कि कैसे बात कर रहे हैं मान, और अब तुम कैसे हो अपने बैक-एंड डेटाबेस में डेटा भंडारण।
संभवत: आपके डेटाबेस को जानकारी को सॉर्ट और विश्लेषण करने में सक्षम होना चाहते हैं, उदाहरण के लिए आपके डेटाबेस को अलग-अलग फ़ील्ड के रूप में स्टोर करने की आवश्यकता होगी (उदाहरण के लिए रिपोर्टिंग और आंकड़े उद्देश्यों के लिए)।
इस मामले में, मुझे लगता है कि यह इस बात पर निर्भर करेगा कि आप कितने आश्वस्त हैं कि आप संबोधित जानकारी को अपने व्यक्तिगत क्षेत्रों में सही तरीके से पार्स कर सकते हैं।
एक हाइब्रिड विकल्प उपयोगकर्ता को एक पंक्ति के रूप में पता दर्ज करने की अनुमति देगा, और फिर अलग-अलग फ़ील्ड में जानकारी का सर्वोत्तम प्रयास पार्सिंग करें। यह समान है कि Outlook संपर्कों के लिए पते कैसे प्रबंधित करता है - आप सभी जानकारी को एक ज्ञापन फ़ील्ड में दर्ज करते हैं, और फिर यह आपके लिए विभाजित होता है। यदि आप किसी भी फ़ील्ड को गलत समझते हैं तो आप सही कर सकते हैं।
मेरी राय में, हाइब्रिड विधि जाने का रास्ता है। जब तक मुझे कुछ भेज दिया नहीं जाता है और यह सुनिश्चित करने की आवश्यकता होती है कि पता सही तरीके से पार्स हो जाए, तो मैं इसे खराब करता हूं जब खराब रूप से डिज़ाइन की गई साइटें मुझे अपने पते को विभाजित करने के लिए मजबूर करती हैं। – albertb
मैं इसे विभाजित करता हूं, पते के एक विशिष्ट अनुभाग के लिए खोज करने की अनुमति देता है और आप उन पते को सीमित कर सकते हैं जिन्हें आप स्वरूपण को जानकर संभालना चाहते हैं यानी केवल पूर्वी तट पते पर शिप करें।
सहमत हैं कि इनपुट के साथ आप इसे कम करने के साथ क्या करना चाहते हैं क्योंकि इसे बाद में खोजना है। – Riri
मैं केवल एक टेक्स्ट फ़ील्ड रखने के खिलाफ बहुत अधिक होगा जहां उपयोगकर्ता अपना पता दर्ज करते हैं। यदि आप के लिए कोई विशिष्ट फ़ील्ड नहीं है तो आप आश्चर्यचकित होंगे कि कितने लोग अपने ज़िप कोड या कुछ अन्य महत्वपूर्ण जानकारी छोड़ देंगे। साथ ही, जैसा कि अन्य ने उल्लेख किया है, यह बाद में इस जानकारी पर रिपोर्ट करने के लिए रिपोर्टिंग को अधिक आसान बनाता है यदि सभी डेटा पूर्व-विश्लेषण किया गया है। जैसा कि अन्य उपयोगकर्ताओं ने उल्लेख किया है, दृष्टिकोण जैसे कार्यक्रम इस जानकारी को पार्स करेंगे, लेकिन केवल इसलिए कि डेटा का स्रोत अक्सर ईमेल के हस्ताक्षर होते हैं, जो ऐसा कुछ है जो लगातार प्रारूप में नहीं होता है।
1) आपको इसे विभाजित करना चाहिए।
2) क्या आप अंतरराष्ट्रीय पता इनपुट करने का प्रयास करने से पहले this पढ़ सकते हैं?
उस लेख पर निर्भर न करें। लेखक मुद्दों को समझता है लेकिन विवरण का आधा हिस्सा गलत हो जाता है। –
@ विन्डोज प्रोग्रामर: कौन सा आधा? @ क्लाउडियो: विभिन्न पता प्रारूपों का उल्लेख करने के लिए +1 – Treb
मैं किब्बी के साथ सहमत हूं। मैं यह भी देखकर आश्चर्यचकित था कि लोग पहले और आखिरी नाम, पोस्टल कोड और शहर इत्यादि को बदलते हुए क्षेत्र के लेबल भी नहीं पढ़ते हैं।
नहीं, आप यह निर्धारित नहीं कर सकते कि कोई डाक कोड मान्य है या नहीं, वेब एप्लिकेशन लक्ष्यीकरण में अंतरराष्ट्रीय ग्राहकों ...
कुछ देशों में डाक कोड, विभिन्न लंबाई, कोई राज्य जानकारी आदि में अल्फा वर्ण हैं।
हालांकि कुछ देशों के लिए डाक कोड मान्य करने का प्रयास करना संभव है, लेकिन आपके डेटासॉर के पास सही कोड होने की कोई गारंटी नहीं है, इसलिए यह एक दिशानिर्देश होना चाहिए, न कि नियम। मेरा शहर एक ज़िप कोड से दो में विभाजित है; मेरा वही रहा, लेकिन कई साइटों ने सोचा कि यह बदल गया है ... –
... और उन लोगों से संपर्क करना बहुत निराशाजनक था जो मुझे इसे सही करने नहीं देते और समझाते थे कि उनके पास ज़िप कोड गलत था। –
निश्चित रूप से इनपुट को विभाजित करें। यदि आप इसकी मदद कर सकते हैं - और आपकी व्यावसायिक आवश्यकताओं के आधार पर - प्रविष्टि के बिंदु पर पता सत्यापन करना बुद्धिमान हो सकता है।यह आपको यह जानने की अनुमति देगा कि आपके पते आपके डेटाबेस में जा रहे हैं और आपको धोखाधड़ी की रोकथाम जैसी कई अन्य चीजें करने की अनुमति देता है। एक सत्यापित पता होने से शिपिंग लागत कम करने में मदद मिल सकती है यदि आप अपने ग्राहकों को भौतिक सामान भेज रहे हैं और एवीएस सत्यापन के दौरान सही ज़िप कोड जमा करके क्रेडिट कार्ड मर्चेंट फीस को कम करने में मदद कर सकते हैं।
पूर्ण प्रकटीकरण के हित में, मैं SmartyStreets के संस्थापक हूं। हम CASS-certified address verification सेवाएं प्रदान करते हैं। उपयोगकर्ता हमारी वेबसाइट पर list for scrubbing (सीएसवी/एक्सेल/आदि) अपलोड कर सकते हैं या हमारे address verification web service API को लाइवएड्रेस नामक उपयोग कर सकते हैं।
ध्यान दें कि सही पार्सिंग महत्वपूर्ण नहीं है (उदाहरण के लिए मानचित्र।) चेकआउट के मामले में, आपको अभी भी विभिन्न फ़ील्ड भरने की आवश्यकता है, तो Google केवल एक बॉक्स मॉडल का उपयोग करता है। – albertb
@albertb चेकआउट के लिए इनपुट फ़ील्ड को विभाजित करने की आवश्यकता नहीं है। [यह पोस्ट UX.SE] पर देखें (http://ux.stackexchange.com/questions/22196/combining-all-the-address-fields-into-one) और [यह एक फ्रीफॉर्म पतों को पार्स करने के बारे में SO पर] [ http://stackoverflow.com/questions/11160192/how-to-parse-freeform-street-postal-address-into-components) - यह * किया जा सकता है, और विश्वसनीय रूप से किया जा सकता है। – Matt