ग्राहक सूचना रिकॉर्ड के लिए डी-फैक्टो मानक [बंद]

Question

मैं वर्तमान में एक संभावित नई परियोजना का मूल्यांकन कर रहा हूं जिसमें विशिष्ट ग्राहक जानकारी (उपयोगकर्ता नाम, pwd, पहला और अंतिम नाम, ईमेल, पता, telfnr ...) के लिए DB बनाना शामिल है। इस बिंदु पर, आवश्यकताओं को केवल मोटे तौर पर परिभाषित किया जाता है।

ग्राहक DB रिकॉर्ड्स के O (लाखों) में होने की उम्मीद है। DB के आकार और संभावित DB विकल्पों और आर्किटेक्चर का मूल्यांकन करने के लिए कुछ बैक-ऑफ-द-लिफाफा संख्याओं की गणना करने के लिए, मैं इस तरह के रिकॉर्ड के लिए कुछ वास्तविक मानकों की तलाश कर रहा हूं। विशेष रूप से, एक साधारण ग्राहक रिकॉर्ड के लिए हर क्षेत्र का std आकार (पहला नाम, अंतिम नाम, पता, ...) या विशिष्ट औसत होगा ।

इतनी सारी ई-कॉमर्स वेबसाइट्स के साथ, किसी प्रकार का विशिष्ट कॉन्फ़िगरेशन होना चाहिए जिसका पुन: उपयोग किया जा सकता है और पहिया को फिर से आविष्कार करने से बचना चाहिए।

कोई विचार?

---- संपादित करें ----

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

Comments

मैं इस पर भी जानकारी देखना चाहूंगा। मुझे हालांकि ऐसा कुछ भी कभी नहीं मिला। क्या होगा अगर कोई व्यक्ति किसी ओपन सोर्स प्रोजेक्ट को देखकर इस पर केस स्टडी करे तो दिलचस्प होगा।

— प्रोग्रामर

अफ़सोस कि आपको अपने स्वयं के रिकॉर्ड प्रारूप को फिर से नहीं बनाने के द्वारा सॉफ़्टवेयर 'व्यावसायिकता' के बारे में एक अच्छा सवाल है।

— 15 अप्रैल को gbjbaanb

यार, मैं चाहता हूं कि इस क्षेत्र में किसी प्रकार की निरंतरता हो। मैंने अच्छी संख्या में सिस्टम से ग्राहक डेटाबेस आयात किए हैं, और वे सभी नक्शे पर हैं।

— तेहर्रीके

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

— HLGEM

रिटेल टेक्नोलॉजी स्टैंडर्ड्स डेटा मॉडल होम पेज के लिए एसोसिएशन की

— उपयोगकर्ता

Answer 1

मानकों के बारे में अच्छी बात यह है कि आपके पास चुनने के लिए बहुत सारे हैं। - एंड्रयू स्टुअर्ट तानेनबूम

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

आपके द्वारा डिज़ाइन या जानकारी के लिए कोई शाही सड़क नहीं है। आवश्यकताओं को पूरा करने के लिए समय और प्रयास करें और एक ठोस अनुमान प्राप्त करें। अन्यथा आप सही से ज्यादा गलत होंगे। यह जानने का एकमात्र तरीका है कि आपको क्या जानना चाहिए, यह सवाल पूछना है और इसे स्वयं पता लगाना है।

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

मैंने पिछले 20 वर्षों में कम से कम 8 कस्टम सीआरएम समाधानों का डिज़ाइन और निर्माण किया है, प्रत्येक और सभी की अलग-अलग आवश्यकताएं थीं और सभी डोमेन के लिए डेटा मॉडल (तार्किक या भौतिक) में से किसी ने भी काम नहीं किया होगा।

विशिष्ट मामलों के लिए विशिष्ट समाधान हमेशा बेहतर डिजाइन होंगे।

Comments

काश मैं अंतिम वाक्य के लिए +2 कर पाता!

— मैक्सएम

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

— मस्तक

मेरी बात याद आती है, व्यापक रूप से इस्तेमाल की जाने वाली कोई भी चीज उपयोगी होने के लिए बहुत व्यापक और सामान्यीकृत है। यह फूला हुआ और अत्यधिक जटिल होगा। यह वह जगह है जहाँ SAP, PeopleSoft और Salesforce अपना पैसा बनाते हैं। उनके सामान को इस तरह से सामान्यीकृत किया जाता है और आपको अपनी कंपनियों की आवश्यकताओं के अनुसार इसे अनुकूलित करने के लिए उच्च $ $ $ सलाहकार का भुगतान करना पड़ता है। आमतौर पर यह लागत कई बार एक सीधे कस्टम समाधान के विकास और रखरखाव के लिए खर्च होती है। और वे लगातार असंगत उन्नयन और पसंद के साथ, काम के बाद जाने पर अपना पैसा बनाते हैं।

Answer 2

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

Comments

वह निकटतम है जो मैं अपने प्रश्न के उत्तर में आया हूं। वे दिशा-निर्देश काफी अच्छे हैं, हालांकि पूर्ण या ठोस नहीं हैं, लेकिन निश्चित रूप से सही भावना में हैं।

— मास

Answer 3

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

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

Answer 4

मौजूदा अंतर्राष्ट्रीय मानक

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

उदाहरण के लिए, लेकिन (इन दोनों के साथ अनुभव से बात करना) तक सीमित नहीं है:

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

• इलेक्ट्रॉनिक स्वास्थ्य रिकॉर्ड और उनके तकनीकी मानकों का व्यापक क्षेत्र

• सॉफ्टवेयर मोबाइल ऑपरेटरों के कॉल डेटा रिकॉर्ड और सेवा डेटा रिकॉर्ड (बिल्कुल मानक के रूप में नहीं, बल्कि साझेदार नेटवर्क के बीच अंतर के लिए) के साथ काम कर रहा है।

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

आंतरिक रिकॉर्ड के लिए सरकार द्वारा संचालित मानक

सरकारों, राष्ट्रीय या स्थानीय, को अक्सर सार्वजनिक कार्यालयों के लिए व्यक्तिगत जानकारी को रिकॉर्ड करने और संग्रहीत करने की एक मजबूत आवश्यकता होती है, और जाहिर है कि वे स्वयं "मानकों" के साथ आए हैं, जिसे वे अपने संगठनों में लागू करते हैं (भागीदार संगठनों के साथ सफलता और अंतर के विभिन्न स्तरों के साथ) ।

एक उदाहरण न्यूजीलैंड सरकार की पहचान रिकॉर्ड्स स्टैंडर्ड के लिए यह डेटा प्रारूप हो सकता है ।

सॉफ्टवेयर में डी-फैक्टो मानक

आप इनसे प्रेरणा ले सकते हैं, या अपने ग्राहक डेटा के डेटा विनिर्देशों के लिए सर्वोत्तम-प्रथाओं और दिशानिर्देशों के रूप में उपयोग करने के लिए ज्ञात ओपन-सोर्स सीआरएम सॉफ़्टवेयर के स्रोत का उपयोग कर सकते हैं।

देखें शीर्ष 10 ओपन-सोर्स व्यापार और सामाजिक सीआरएम सॉफ्टवेयर सूची, जिसके लिए आप अपने डेटा मॉडल अपने आप को देखने के लिए कर सकता है।

Comments

De-Facto Standards in Software-> इनमें बहुत रुचि है। क्या आप कुछ संदर्भ जोड़ सकते हैं?

— मासग

डाउनवोटर्स, कृपया समझाएं (अभी 2 थे)।

— जाइल

Answer 5

मैं कहता हूँ कि आपको ईडीआई सिस्टम के लिए मानक खोजने होंगे । सैकड़ों 'मानक' दस्तावेज हैं, इसलिए आपको अपनी आवश्यकताओं के आधार पर एक का चयन करना होगा। उदाहरण के लिए, यहां TRADACOMS इनवॉइस के लिए एक प्रारूप है जिसे आप उन क्षेत्रों को पकड़ सकते हैं जिनसे आप चाहते हैं।

Answer 6

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

Answer 7

मैं कहूंगा कि "आपको इसकी आवश्यकता नहीं है (अभी तक)"। और रॉन जेफ्रीस के साथ: "हमेशा उन चीजों को लागू करें जब आपको वास्तव में उनकी आवश्यकता होती है, कभी नहीं जब आप सिर्फ यह सोचते हैं कि आपको उनकी आवश्यकता है।"

इसलिए हो सकता है कि अगर यह उस परियोजना के लिए एक ठोस डेटाबेस जोड़ने का समय है जो आपके पास उस डेटा के बारे में बहुत अधिक ज्ञान है जो वहां संग्रहीत किया जाएगा।