पता पुस्तिका डेटाबेस डिज़ाइन: denormalize?

Question

मैं एक संपर्क प्रबंधक/पता पुस्तिका जैसी एप्लिकेशन तैयार कर रहा हूं लेकिन डेटाबेस डिज़ाइन पर व्यवस्थित नहीं हो सकता।

मेरे वर्तमान सेटअप में मेरे पास एक संपर्क है, जिसमें पता, फोनेनबर्स, ईमेल और संगठन हैं। सभी संपर्क गुण वर्तमान में संपर्क तालिका में एक एफके के साथ अलग टेबल हैं। एक संपर्क कहने की जरूरत नहीं है इन गुणों में से कोई भी संख्या हो सकती है।

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

उदा।, 3 प्रविष्टियों के साथ एक फोनेनंबर तालिका में एक एफके के साथ संपर्क के बजाय, बस सभी फोननबर्स को एन्कोड करें और उन्हें संपर्क तालिका के क्षेत्र में स्टोर करें?

कोई अंतर्दृष्टि वास्तव में सराहना की! (fyi मैं Django का उपयोग कर रहा हूं हालांकि यह वास्तव में कोई फर्क नहीं पड़ता)

Answer 1

क्या आप गारंटी दे सकते हैं कि आपका ऐप इन अन्य कार्यक्षमताओं की आवश्यकता के लिए कभी नहीं बढ़ेगा? क्या आप वास्तव में कोने में खुद को पेंट करना चाहते हैं जैसे कि आप बाद में इन सबको आसानी से समर्थन नहीं दे सकते?

आम तौर पर, denormalization केवल preformance कारणों के लिए होता है। और फिर, सामान्यीकृत डेटा की एक प्रति अभी भी लाइव काम के लिए रखी जाती है और ऑफ़लाइन प्रोसेसिंग के लिए denormalized डेटा का उपयोग किया जाता है जहां एक स्थिर स्नैपशॉट ठीक है।

जॉइन लिखने के लिए उपयोग करें। एसक्यूएल काम करता है। ऐसा करने का मतलब यह नहीं है कि कुछ गलत है।

Answer 2

मुझे पता है कि मैं बहुत देर हो चुकी हूं, लेकिन किसी भी मुद्दे के लिए।

आईएमओ, इस मामले में मेटाडाटा मॉडलिंग जाने का तरीका है। http://searchdatamanagement.techtarget.com/feature/Data-model-patterns-A-metadata-map

Answer 3

लगता है कि आपने वर्तमान में पांच एसक्यूएल टेबल के रूप में मॉडलिंग की डेटा ले और यह एक आम बहु-मान प्रकार में कनवर्ट (करता है अपने एसक्यूएल उत्पाद इस के लिए अच्छा समर्थन है?) एक ही रास्ता मैं देख सकता हूँ इस का गठन होगा 'प्रस्ताव denormalization 'होगा अगर आप 1NF का उल्लंघन करने का प्रस्ताव कर रहे थे, तो आप किस बिंदु पर एसक्यूएल को डेटा स्टोर के रूप में छोड़ सकते हैं क्योंकि आपका डेटा अब संबंधपरक नहीं होगा! अन्यथा, आपका डेटा अभी भी सामान्यीकृत होगा लेकिन आप SQL का उपयोग करके अपने विशेषताओं से पूछताछ करने की क्षमता खो देंगे (जब तक आपके SQL उत्पाद में बहु-मान गुणों की क्वेरी करने के लिए एक्सटेंशन नहीं हैं)। निर्णायक कारक लगता है: क्या आपको SQL का उपयोग करके इन विशेषताओं से पूछताछ करने की आवश्यकता है?