हम सभी वहां मौजूद हैं - निम्नलिखित उदाहरण पर विचार करें - पहले, ग्राहक कहता है "प्रत्येक उपयोगकर्ता के पास केवल एक प्रोफ़ाइल तस्वीर होगी", इसलिए हम उपयोगकर्ताओं के लिए एक फ़ील्ड जोड़ते हैं - आधा साल बाद , आवश्यकताएं बदलती हैं और उपयोगकर्ता को वास्तव में एन प्रोफाइल चित्रों की आवश्यकता होती है।तीन आयामी डेटाबेस तालिका
अब, यह केवल तभी संभव लगता है जब आप नई कार्डिनिटी 1: 1 के बजाय नई कार्डिनालिटी 1: n को संभालने के लिए उपयोगकर्ता_पिक्चर जैसे नई तालिका जोड़ते हैं। अक्सर यह बहुत जटिल हो सकता है। जब भी मैं इस समस्या को पूरा करता हूं, मुझे आश्चर्य है कि हम उन सभी तीन आयामों का उपयोग क्यों नहीं करते हैं जिन्हें हम सोच सकते हैं। एक दो आयामी तालिका इस तरह से सीमित है कि यह कुछ अपूर्ण है - क्या होगा यदि प्रोफ़ाइल चित्र के साथ हमारी समस्या का जिक्र है दोबारा, उपयोगकर्ता तालिका में चित्र फ़ील्ड में गहराई थी, और उस गहराई ने फ़ील्ड को एक सरणी बना दी जो पूरी तरह से दोनों कार्डिनियलिटी 1: 1 और 1: n दोनों का प्रतिनिधित्व करती थी।
टेबल फ़ील्ड बस सरणी बन जाएंगे और स्वचालित रूप से दोनों कार्डिनियलिटी का समर्थन करेंगे - क्या ऐसा कुछ नहीं होगा? कम से कम मैं इसका इस्तेमाल करूंगा। क्या वहां पहले से कुछ ऐसा है?
डेटाबेस में "चीजों" के बीच सभी संभावित संबंध (एक-से-एक, एक से कई, कई से कई), कवर किए गए हैं। "त्रि-आयामी" तालिका के लिए उपयोग केस क्या होगा - जिसका अर्थ है? – NullUserException
एक उदाहरण का उपयोग केस प्रोफाइल चित्रों के ऊपर एक है: आपको एक नई तालिका जोड़ने की आवश्यकता होगी, लेकिन यह स्पष्ट रूप से बोझिल है। मॉडल संबंधों को बदलने की आवश्यकता होगी, तदनुसार अद्यतन प्रश्न, आदि - जिसमें बहुत सारे दर्द और काम शामिल हैं। मुझे लगता है कि हम उससे बेहतर करने में सक्षम हैं। एक दो आयामी क्षेत्र नहीं होगा, तालिका को तीन आयामी बना देगा, इसे हल करें? – weltschmerz
रिलेशनल डेटाबेस एक बहुत ही ठोस नींव - [रिलेशनल बीजगणित] (http://en.wikipedia.org/wiki/Relational_algebra) द्वारा समर्थित हैं। यह सुनिश्चित करता है कि वे दोनों तेज़ और सही हैं। यही कारण है कि वे अभी भी आसपास क्यों हैं जब अन्य प्रकार के डेटाबेस आए और वर्षों से चले गए। जो टूटा नहीं है उसे ठीक न करें। – NullUserException