कई रिश्तों के लिए कई

Question

मेरे पास एक ग्राहक और प्रबंधक हैं, दो टेबल स्वतंत्र रूप से। मेरी ग्राहक तालिका में लगभग सौ मिलियन रिकॉर्ड हैं जबकि प्रबंधक तालिका में 100 रिकॉर्ड हैं। अब मैं ग्राहकों को मैनेजर को मैप करने की स्थिति में हूं। नियम निम्नानुसार हैं

1. एक प्रबंधक के पास कई ग्राहक हो सकते हैं।
2. एक ग्राहक एकाधिक प्रबंधकों के साथ मैप किया जा सकता है।

इसे हल करने के लिए सबसे अच्छा डीबी डिजाइन क्या है? सक्षम प्रबंधक बनाएँ कस्टमर मैपिंग एक विचार है। लेकिन मैं इसके साथ खुश नहीं हूँ। इस वजह से मुझे एक बहुत बड़ी मेज का नेतृत्व किया। उदाहरण के लिए। यदि प्रबंधक 1 और प्रबंधक 2 सभी ग्राहकों के साथ मैप किया गया है तो इस तालिका में 2 सौ लाख रिकॉर्ड हैं।

Answer 1

आपकी गलतफहमी के बावजूद सर्वश्रेष्ठ डीबी डिज़ाइन, वही है जो आपने वर्णित किया है। दूसरे शब्दों में, मैपिंग टेबल ManagerCustomerMapping है।

हमेशा 3 एनएफ से शुरू होता है और केवल तभी संशोधित होता है जब असली प्रदर्शन समस्याएं होती हैं जिन्हें अन्य तरीकों से हल नहीं किया जा सकता है।

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

और हाँ, यदि प्रत्येक ग्राहक दो अलग-अलग प्रबंधकों के लिए मानचित्र करता है, तो आपके पास 200 मिलियन रिकॉर्ड होंगे। वह कोई समस्या नहीं है। दुकानों की तरह मैं काम करता हूं (सिस्टम जेड पर डीबी 2), यह एक मध्यम आकार की टेबल के बारे में है।

एसक्यूएल की सुंदरता यह है कि यदि आप पर्याप्त रूप से पर्याप्त प्रदर्शन नहीं करते हैं तो आप ज्यादातर डीबीएमएस को स्वैप कर सकते हैं। दो आईडी स्तंभों की

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

Answer 2

आपकी संख्या काफी दिलचस्प है। खाता प्रबंधक कितने ग्राहक जान सकते हैं - 100? आपके पास कितने प्रबंधक हैं, 1 एम? क्या एक बिक्री व्यक्ति बेहतर विवरण होगा?

TABLE dimCustomer (KeyCustomer, Name, Address, ...etc) 
TABLE dimSalesPerson (KeySalesPeson, Name, Phone, Area, ...etc) 
TABLE dimProduct (KeyProduct, Description, CatalogPrice, ...etc) 
TABLE dimDate (KeyDate, FullDate, Year, Month, DayOfWeek, IsHoliday, etc...) 
TABLE factSales (KeyCustomer, KeyProduct, KeySalesPerson, KeyDate, Quantity, Ammount, OrderID, ..) 

factSales तालिका हर आइटम, बेशक बड़ी मेज की बिक्री पर कब्जा होगा, लेकिन आप की जरूरत नहीं होगी: यदि हां, तो हो सकता है आप पर विचार करना चाहिए डेटा गोदाम (DW) दृष्टिकोण, उदाहरण के लिए एक Kimball स्टार की तरह दिखेगा ग्राहकों को मैनेजर को मैप करने के लिए, बस तथ्य तालिका खोजें और अंतिम बिक्री व्यक्ति ढूंढें जिसने ग्राहक से संपर्क किया था। किसी भी तरह से मुझे लगता है कि यह व्यापार मॉडल के करीब हो सकता है।
यदि यह कोई रहस्य नहीं है, तो यह डेटाबेस किस प्रकार का व्यवसाय ट्रैकिंग कर रहा है?

Answer 3

अब पकड़ो। आप बताते हैं कि एक प्रबंधक को सभी ग्राहकों को सौंपा जा सकता है? एक प्रबंधक के लिए सौ मिलियन ग्राहकों के लिए ज़िम्मेदार हो सकता है? ईमानदारी से, ऐसा लगता है कि कुछ गड़बड़ है।

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

आप बहु-स्तर के विपणन संगठनों में और इस तरह के कुछ उद्योगों में कमीशन सिस्टम में इस तरह की संरचना देखते हैं (मैं बस दूसरे दिन बीमा में आया था)।

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