किसी भी डेटाबेस में मोटे तौर पर 2 प्रकार की तालिकाएँ होती हैं - आयाम और तथ्य:

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

डेटाबेस स्कीमा डिज़ाइन करते समय, निम्नलिखित कुछ दिशानिर्देश इसे सही ढंग से करने में मदद करते हैं।

पहले सामान्य

भले ही डेटाबेस SQL ​​या NoSQL होगा, सामान्यीकृत स्कीमा परिप्रेक्ष्य से एक बार इकाइयों/ऑब्जेक्ट्स और इसलिए तालिकाओं के बारे में सोचना उपयोगी है। सामान्यीकृत स्कीमा संस्थाओं, रिश्तों और क्षेत्रों पर स्पष्टता देती है। इससे सामान्यीकरण या NoSQL में रूपांतरण सीधा और एक सचेत डिजाइन हो सकता है।

वास्तविक दुनिया की संस्थाओं को प्रतिबिंबित करें

भले ही उपयोग के मामले/रिपोर्ट अस्पष्ट हों, स्कीमा इकाइयों को वास्तविक दुनिया के उपयोग के मामले को प्रतिबिंबित करना चाहिए। ऐसी स्कीम आमतौर पर मजबूत होती है।

निम्नलिखित में से कोई भी आम तौर पर विभिन्न संस्थाओं और इसलिए तालिकाओं की पहचान करने और बनाने के मामले हैं:

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

यदि किसी फ़ील्ड का उपयोग क्वेरीज़, खोज या सॉर्टिंग में किया जा रहा है, तो डिफ़ॉल्ट रूप से इसके लिए इंडेक्स जोड़ें। इन क्षेत्रों के लिए सरल अनुक्रमणिका डिफ़ॉल्ट रूप से चालू होनी चाहिए क्योंकि उनका अधिकतम लाभ होता है। इंडेक्स न जोड़ना एक सचेत विकल्प होना चाहिए, न कि डिफ़ॉल्ट स्थिति।

सही फ़ील्ड प्रकार का उपयोग करें

1. विकल्प मानों के निश्चित सेट वाले फ़ील्ड के लिए गणना बनाम स्ट्रिंग प्रकार: गणनाओं को बाइट के रूप में कार्यान्वित किया जाता है, इसलिए कम जगह लेते हैं (उदाहरण के लिए 1-4 बाइट लंबी बाइट/लंबी/इंट बनाम 128-बाइट स्ट्रिंग), इंडेक्स पर तेज/तेज होते हैं और खोजता है. बड़ी तालिकाओं के लिए, स्थान और प्रदर्शन आवश्यकताएँ बढ़ जाती हैं। डिफ़ॉल्ट रूप से गणनाओं का उपयोग करें.
2. प्राथमिक कुंजी (आईडी) प्रकार: प्रदर्शन और भंडारण के लिहाज से - हमेशा एक निश्चित आकार की कुंजी का उपयोग करने की सलाह दी जाती है - यानी पूर्णांक या यूयूआईडी।
3. सामान्य तालिका फ़ील्ड: सभी ORM इकाइयों में कुछ फ़ील्ड सुझाए गए हैं जो बदल सकते हैं - यानी create_at, update_at, create_by, update_by। इसके अतिरिक्त, उन संस्थाओं के लिए जिनके पास अक्सर विदेशी कुंजी लिंकेज हो सकती हैं और जिन्हें शायद ही कभी हटाया जाता है, यह प्रस्तावित है कि सॉफ्ट डिलीट का उपयोग किया जाए।

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

इतिहास तालिकाएँ कब जोड़ें?

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

ऐसे 2 तरीके हैं जिनसे उनका रखरखाव किया जा सकता है:

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