सबसे अच्छा तरीका मॉडल करने के लिए ग्राहक <--> पता

Question

हर Customer एक भौतिक पता और एक वैकल्पिक डाक पते है। इसे मॉडल करने का आपका पसंदीदा तरीका क्या है?

विकल्प 1. CustomerAddress

 
    Customer (id, phys_address_id, mail_address_id) 
    Address (id, street, city, etc.) 

विकल्प 2. Customer के लिए विदेशी कुंजी Address के लिए एक-से-अनेक संबंध है, जो पता प्रकार

 
    Customer (id) 
    Address (id, customer_id, address_type, street, city, etc.) 

वर्णन करने के लिए एक क्षेत्र शामिल है है

विकल्प 3. पता जानकारी को डी-सामान्यीकृत है और Customer

में संग्रहीत

 
    Customer (id, phys_street, phys_city, etc. mail_street, mail_city, etc.) 

मेरी अधिभावी लक्ष्यों में से एक वस्तु-संबंधपरक मैपिंग आसान बनाने के लिए है, इसलिए मैं पहले दृष्टिकोण की ओर झुकाव रहा हूँ। आपके क्या विचार हैं?

Answer 1

मैं सामान्यीकरण के सभी सामान्य कारणों के लिए पहला दृष्टिकोण की ओर रुख करता हूं। यह दृष्टिकोण मेलिंग विवरणों पर डेटा सफाई करने में भी आसान बनाता है।

आप संभवतः एक से अधिक पते (मेल, आवासीय, आदि) या प्रभावी दिनांकों उपयोग करने के लिए सक्षम होने के लिए चाहते हैं, तो कई मामलों में इस दृष्टिकोण

 
    Customer (id, phys_address_id) 
    Cust_address_type (cust_id, mail_address_id, address_type, start_date, end_date) 
    Address (id, street, city, etc.) 

Answer 2

दूसरा विकल्प शायद मैं जिस तरह से जाऊंगा। और ऑफ-मौके पर यह उपयोगकर्ताओं को अतिरिक्त पता '(यदि आप उन्हें ऐसा करना चाहते थे) जोड़ देंगे, तो वे शिपिंग के लिए इच्छानुसार स्विच कर सकते हैं।

Answer 3

मैं # 1 पसंद करूंगा। अच्छा सामान्यीकरण और स्पष्ट रूप से इरादे से संवाद करता है। यह मॉडल समान पता ऑब्जेक्ट (पंक्ति) दोनों पतेों के लिए उपयोग करने की अनुमति देता है, जो कुछ मैंने काफी मूल्यवान पाया है। इस जानकारी को डुप्लिकेट करने में खो जाना बहुत आसान है।

Answer 4

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

Answer 5

की तरह पर विचार अनुमति देने के लिए जा रहे हैं: यह निर्भर करता है।

अपने ग्राहकों को तो एक से अधिक पते के साथ सौदा तो एक से-अनेक संबंध उपयुक्त होगा। आप पते पर एक झंडा पेश कर सकते हैं जो संकेत करता है कि कोई पता शिपमेंट या बिल इत्यादि के लिए है या नहीं। या आप अलग-अलग तालिकाओं में अलग-अलग पता प्रकारों को स्टोर करते हैं और ग्राहक पर कई से अधिक संबंध रखते हैं।

मामलों में जहां आप केवल एक ग्राहक से एक का पता जानने की जरूरत में क्यों आपको लगता है कि करने के लिए कई मॉडल हैं? एक से एक रिश्ते यहां आपकी ज़रूरतों को पूरा करेगा।

महत्वपूर्ण: यदि आप प्रदर्शन समस्याओं का सामना करते हैं तो केवल तब्दील हो जाएं।

Answer 6

विकल्प 3 अत्यंत सीमित है, और विकल्प 1 स्कीमा बदले बिना अन्य पते के प्रकार के लिए अनुमति देने के लिए नहीं बढ़ाई जा सकती। विकल्प 2 स्पष्ट रूप से सबसे लचीला है और इसलिए सबसे अच्छा विकल्प है।

Answer 7

आप, आप भी यह एक छोटा सा संशोधित कर के लिए एक पता इतिहास रखना चाहते हैं मैं विकल्प 1. के साथ जाना होगा:

Customer (id, phys_address_id, mail_address_id) 
Address (id, customer_id, start_dt, end_dt, street, city, etc.) 

तो पता बदल जाता है, बस तारीख वर्तमान पते समाप्त करने और जोड़ने Address तालिका में एक नया रिकॉर्ड। phys_address_id और mail_address_id हमेशा वर्तमान पते पर इंगित करें।

इस तरह आप पतों की एक इतिहास रख सकते हैं, आप डेटाबेस (mail_address_id में डिफ़ॉल्ट के साथ) में संग्रहीत कई डाक पते सकता है, और भौतिक पता और डाक पते समान हैं अगर आप सिर्फ phys_address_id और mail_address_id आपको बताएंगे एक ही रिकॉर्ड में।

Answer 8

एक महत्वपूर्ण तथ्य जिसे आपको विचार करने की आवश्यकता हो सकती है (आपकी समस्या डोमेन के आधार पर) यह है कि लोग पते बदलते हैं, और हो सकता है कि वे आपको अपने पते में बदलाव से पहले बताएं; यह उपयोगिता कंपनियों, दूरसंचार इत्यादि के लिए निश्चित रूप से सच है

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

Customer (id, ...) 
Address (id, customer_id, address_type, valid_from, valid_to) 

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

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

Answer 9

उन सवालों के जवाब देने पर मुझे DDD के वर्गीकरण का उपयोग करना पसंद है। यदि यह एक इकाई है तो इसमें एक अलग आईडी होना चाहिए, अगर यह एक मूल्य वस्तु है तो इसे नहीं करना चाहिए।

Answer 10

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

जब कोई अतिरिक्त मेलिंग पता की आवश्यकता होती है, तो मैंने इसे एक अलग ऑब्जेक्ट/तालिका में रखा ताकि ग्राहक ऑब्जेक्ट को ज्यादा नाराज न किया जा सके।

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

वर्तमान में हम VerySimpleAddressProtocol लागू करते हैं इस्तेमाल किए गए फ़ील्ड को मानकीकृत करने के लिए आउट प्रोजेक्ट में।

Answer 11

हम इस तरह एक मॉडल के साथ आगे बढ़ रहे हैं:

Person (id, given_name, family_name, title, suffix, birth_date) 
Address (id, culture_id, line1, line2, city, state, zipCode, province, postalCode) 
AddressType (id, descriptiveName) 
PersonAddress (person_id, address_id, addressType_id, activeDates) 

अधिकांश इस अत्यधिक विचार कर सकते हैं। हालांकि, हमारे द्वारा विकसित ऐप्स के बीच एक निर्विवाद आम विषय यह है कि उनमें से कुछ मौलिक संस्थाएं - लोग, संगठन, पता, फोन नंबर इत्यादि होंगे - और वे सभी उन्हें विभिन्न तरीकों से जोड़ना चाहते हैं। इसलिए, हम कुछ सामान्यीकरण में आगे बढ़ रहे हैं कि हम 100% निश्चित हैं जिसके लिए हमने मामलों का उपयोग किया है।

पता तालिका संस्कृति के आधार पर पते को अलग करने के लिए तालिका-प्रति-पदानुक्रम विरासत योजना का पालन करेगी; इसलिए संयुक्त राज्य के पते में एक राज्य और ज़िप क्षेत्र होगा, लेकिन कनाडाई पते में एक प्रांत और डाक कोड होगा।

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

Answer 12

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

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

उदाहरण के लिए, जब ग्राहक एक्स पहले ऑर्डर देता है, तो कोई ग्राहक रिकॉर्ड नहीं बनाया जाता है। इसके बजाए, एक बिक्री आदेश रिकॉर्ड बनाया गया है जिसमें ऑर्डर के समय आवश्यक नाम/कंपनी/पता जानकारी शामिल है। जब ग्राहक एक्स अपना दूसरा ऑर्डर देता है, तो हम ग्राहक फ़ाइल नहीं खोजते हैं, हम बिक्री ऑर्डर फ़ाइल खोजते हैं, फिर उसे अपना दूसरा विक्रय ऑर्डर बनाने के लिए कॉपी/चेन करें। अगर वह अपना नाम/कंपनी/पता जानकारी बदलना चाहता है, ठीक है, तो हम उन क्षेत्रों को बिक्री आदेश # 2 में संपादित करते हैं और बिक्री आदेश # 1 अपरिवर्तित बनी हुई है। अब वह भिन्नता (आदेश 1 या 2) के तहत locatable है।

अन्य कारणों के लिए जब यदि दो ग्राहक रिकॉर्ड वास्तव में ही कर रहे हैं तय करने की कोशिश, http://semaphorecorp.com/mpdd/mpdd.html

Answer 13

अच्छा धागा देखें। मैंने सबसे उपयुक्त स्कीमा पर विचार करने में थोड़ी देर बिताई है और मैंने निष्कर्ष निकाला है कि क्विंटिन-स्टारिन का समाधान सबसे अच्छा है, सिवाय इसके कि मैंने start_date और end_date फ़ील्ड को अपनी व्यक्तित्व तालिका में क्या जोड़ा होगा।मैंने नोट, सक्रिय और को हटाने का भी निर्णय लिया है।

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

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

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

मेरे लिए यह अन्य महत्वपूर्ण पहलू पता तालिका रिकॉर्ड का भविष्य का संपादन है। आप 2 लोग दोनों पर सूचीबद्ध कहना देता है: -

11 जो कुछ भी स्ट्रीट जो शहर Z1P C0D3

यह नहीं एक ही पता तालिका रिकॉर्ड अनुमति देने के लिए खतरनाक विभिन्न संस्थाओं (को सौंपा जा करने के लिए विचार किया जाना चाहिए व्यक्ति, कंपनी)? तो मान लें कि उपयोगकर्ता यह महसूस करता है कि इनमें से एक व्यक्ति 111 में रहता है जो भी स्ट्रीट और एक टाइपो है। यदि आप वह पता बदलते हैं, तो यह दोनों इकाइयों के लिए इसे बदल देगा। मैं इससे बचना चाहूंगा। मेरा सुझाव है कि एमवीसी में मॉडल (मेरे मामले में, PHP Yii2) मौजूदा पता रिकॉर्ड्स के लिए देखें, जब उस ग्राहक से संबंधित होने के लिए ज्ञात एक नया पता बनाया जा रहा है (चयन करें * व्यक्ति से संपर्क करें व्यक्तिगत व्यक्ति पर व्यक्ति .address_id = address.id जहां personaddress.person_id = {वर्तमान व्यक्ति संपादित आईडी हो रहा है}) और उपयोगकर्ता को उस रिकॉर्ड का उपयोग करने का विकल्प प्रदान करें (जैसा कि अनिवार्य रूप से ऊपर सुझाया गया था)।

मैं कई अलग अलग संस्थाओं के लिए एक ही पते जोड़ने लग रहा है बस मुसीबत के लिए पूछ रहा है के रूप में यह पता रिकॉर्ड (अव्यावहारिक) के बाद के संपादन से इनकार का मामला हो सकता है या खतरे में डालकर कि रिकॉर्ड के भविष्य के संपादन कर सकते हैं भ्रष्ट डेटा पता रिकॉर्ड के बाहर अन्य इकाइयों से संबंधित रिकॉर्ड संपादित किया जा रहा है।

मुझे लोगों के विचार सुनना अच्छा लगेगा।