Google Sheet से relational schema: चरण-दर-चरण मॉडलिंग योजना

स्प्रेडशीट डेटाबेस बनते समय गड़बड़ क्यों हो जाती हैं

छोटी सूची के लिए स्प्रेडशीट बढ़िया है। आप कॉलम बदल सकते हैं, कहीं भी नोट जोड़ सकते हैं, और आँकड़ों को आँख से ठीक कर सकते हैं। लेकिन जब फ़ाइल साझा सत्य का स्रोत बन जाती है तो यह लचीलापन टूटने लगता है।

जैसे-जैसे डेटा बढ़ता है, वही समस्याएँ बार-बार दिखती हैं। आप डुप्लीकेट देखते हैं क्योंकि ग्राहक या उत्पाद स्टोर करने की एक ही जगह नहीं है। विरोधी मान मिलते हैं क्योंकि दो पंक्तियाँ एक ही बारे में अलग बताती हैं, जैसे फ़ोन नंबर। फ़िल्टरिंग और रिपोर्टिंग परेशान करने वाली बन जाती है क्योंकि कुछ कॉलम लिस्ट छिपाते हैं ("Tags", "Products", "Attendees") या फॉर्मैट मिलाते हैं ("$1,200", "1200", "1.2k").

Google Sheet से relational schema पर जाना सुरक्षा के बारे में है। डेटाबेस स्पष्ट संरचना मजबूर करता है ताकि आप क्वेरी, वैलिडेट और अपडेट कर सकें बिना नए विरोधाभास बनाए।

एक उपयोगी मानसिक मॉडल: एक पंक्ति को एक वास्तविक चीज़ दर्शानी चाहिए। अगर एक पंक्ति एक deal, एक customer, और products की सूची तीनों को दर्शाती है, तो बाद में किसी एक को अपडेट करना दर्दनाक होगा।

एक त्वरित परीक्षण: क्या किसी एक पंक्ति को कभी किसी फ़ील्ड के लिए दो मान चाहिए?

• एक ऑर्डर में कई प्रोडक्ट हो सकते हैं
• एक प्रोजेक्ट में कई टीम सदस्य हो सकते हैं
• एक ग्राहक के कई पते हो सकते हैं

अगर जवाब हां है, तो यह "wide row" की समस्या नहीं है। यह "अलग तालिका" की समस्या है। एक बार जब आप इसे साफ़ मॉडल कर लेते हैं, तो आप नाज़ुक मैन्युअल संपादनों पर निर्भर रहने के बजाय फॉर्म और वैलिडेशन बना सकते हैं।

सबसे पहले तय करें कि शीट का असल मतलब क्या है

एक स्प्रेडशीट व्यवस्थित दिख सकती है और फिर भी अलग लोगों के लिए अलग अर्थ रख सकती है। Google Sheet को relational schema में बदलने से पहले, इस बात पर सहमति बनाएं कि शीट क्या ट्रैक कर रही है।

कॉलम्स के बजाय आउटकॉम्स से शुरू करें। डेटा किन निर्णयों का समर्थन करना चाहिए: साप्ताहिक राजस्व रिपोर्ट, विलंबित टिकटों की सूची, फॉलो-अप असाइन करने वाला वर्कफ़्लो, या ग्राहक कॉल के दौरान त्वरित लुकअप? अगर आप किसी निर्णय का नाम नहीं दे सकते, तो अक्सर वह फ़ील्ड डेटाबेस में नहीं होना चाहिए।

फिर हेडर्स और नोट्स में छिपे संज्ञाओं को निकालें। ये आम तौर पर आपकी भविष्य की टेबल बनती हैं: customers, orders, products, invoices, tickets, agents, locations। अगर कोई कॉलम दो संज्ञाओं को मिलाता है (जैसे “Customer + Company”), तो आप कई चीज़ें एक जगह स्टोर कर रहे हैं।

शुरू में परिभाषाओं पर सहमति बनाएं

छोटी अर्थ संबंधी अंतर बाद में बड़ी सफ़ाई बन जाते हैं। बुनियादी बातों पर स्पष्ट रहिए:

• “order” क्या गिना जाएगा (एक quote, एक भुगतान किया गया ख़रीद, या दोनों)?
• “customer” क्या है (व्यक्ति, कंपनी, या दोनों)?
• क्या एक order में कई products हो सकते हैं?
• क्या एक ईमेल कई ग्राहकों से संबंधित हो सकता है?
• “status” किस चीज़ को दिखाने के लिए है (वर्तमान स्थिति या इतिहास)?

उदाहरण: अगर आपकी शीट में एक पंक्ति प्रति “Order” है लेकिन “Products” सेल में कॉमा-सेपरेटेड सूची है, तो तय करें कि वह पंक्ति चेकआउट, शिपमेंट, या इनवॉइस को दर्शाती है। हर विकल्प अलग स्कीमा की ओर ले जाता है।

मूल शीट की एक प्रति रीड-ओनली बनाकर फ्रीज़ करें। आप इसकी मदद से सत्यापित करेंगे कि नई तालिकाएँ अभी भी वही प्रश्न जवाब दे रही हैं।

शीट को साफ़ करें ताकि संरचना दिखे

Google Sheet को relational schema में बदलने से पहले, शीट को डेटा की तरह दिखाएँ, रिपोर्ट की तरह नहीं। डेटाबेस को सुसंगत पंक्तियाँ और कॉलम चाहिए। सजावटी लेआउट उन पैटर्न को छिपाता है जिन्हें आपको मॉडल करना है।

मर्ज्ड सेल, कई हेडर रो, और डेटा रेंज के भीतर सबटोटल जैसी लेआउट चालाकियाँ हटाएँ। एक हेडर रो रखें और फिर केवल रिकॉर्ड की पंक्तियाँ। अगर आपको टोटल चाहिए, तो उन्हें अलग सारांश टैब पर रखें ताकि वे असली रिकॉर्ड्स में मिल न जाएँ।

फिर प्रत्येक कॉलम में फ़ॉर्मैट संगत रखें। डेटाबेस यह अनुमान नहीं लगा सकता कि “1/2/24”, “2024-02-01”, और “Feb 1” एक ही तारीख़ हैं। वही फोन नंबर, मुद्रा, और नामों पर भी लागू होता है। एक फ़ॉर्मैट चुनें और हर जगह उपयोग करें, भले ही यह कड़ा लगे।

एक छोटा क्लीनअप पास जो अक्सर फायदेमंद होता है:

• सुनिश्चित करें कि हर पंक्ति एक चीज़ का प्रतिनिधित्व करे (एक order, एक customer, एक ticket)।
• खाली स्पेसिंग पंक्तियाँ और कॉलम हटा दें।
• “N/A”, “-”, और खाली स्ट्रिंग को एक नियम से बदलें जिसे आप बनाए रखेंगे।
• चिह्नित करें कि कौन से कॉलम गणना किये जाते हैं और कौनसे व्यक्ति द्वारा टाइप किए जाते हैं।

अंत में, उन कक्षों को फ्लैग करें जिनमें कई मान हैं, जैसे एक कॉलम में “red, blue, green”। अभी स्कीमा को ठीक मत कीजिए। केवल उन कॉलमों को चिन्हित करें ताकि आपको याद रहे कि बाद में वे अलग पंक्तियाँ बनेंगे।

रिपीटिंग ग्रुप्स और लिस्ट छिपाने वाले फ़ील्ड्स की पहचान करें

स्प्रेडशीट डेटा मॉडलिंग में सबसे बड़ा चेतावनी संकेत पुनरावृत्ति है। शीट अक्सर "एक से अधिक चीज़" को एक पंक्ति में सिकोड़ देती है, कॉलम दोहराकर या एक सेल में कई मान पैक करके। यह त्वरित ट्रैकिंग के लिए काम करता है, फिर टूट जाता है जब आपको फ़िल्टरिंग, रिपोर्टिंग, या सुसंगत अपडेट चाहिए होते हैं।

वे पैटर्न जो अक्सर “यह दूसरी तालिका होनी चाहिए” कहना चाहते हैं

इन आकृतियों के लिए स्कैन करें:

• नम्बर किए हुए कॉलम जैसे Item 1, Item 2, Item 3 या Phone 1, Phone 2।
• "Home" और "Work" के लिए डुप्लीकेट किए गए पता फ़ील्ड्स जैसे दोहराए ब्लॉक्स।
• कॉमा, लाइन ब्रेक, या “and” से जुड़े सेल जो मान मिलाते हैं (उदाहरण: “Mouse, Keyboard, Monitor”)।
• एक कॉलम जो दो अवधारणाओं को मिलाता है, जैसे “Approved 2025-01-10” या “Alex (Manager)”。
• एक पंक्ति जो एक साथ दो स्तरों का प्रतिनिधित्व करती है, जैसे एक Order पंक्ति जो सभी Order Items को स्टोर करने की कोशिश करती है।

उदाहरण: अगर आपकी सेल्स ट्रैकर Order ID, Customer, Product 1, Qty 1, Product 2, Qty 2 का उपयोग करता है, तो आप दीवार पर टकराएँगे। कुछ ऑर्डर में 1 आइटम होगा, कुछ में 8। शीट या तो अनंत रूप से चौड़ائی में बढ़ेगी या डेटा खोने लगेगा। रिलेशनल मॉडल में, "Orders" एक तालिका बनीगी, और "Order Items" दूसरी तालिका जिसमें हर ऑर्डर पर हर उत्पाद के लिए एक पंक्ति होगी।

"लिस्ट इन ए सेल" के लिए, हर मान को अपना रिकॉर्ड मानकर देखें। “Email, SMS” जैसा सेल आमतौर पर मतलब है कि आपको चैनलों को साफ़ रखने के लिए एक अलग तालिका (या जॉइन टेबल) की जरूरत है।

मिश्रित कॉलम शांत होते हैं पर उतने ही जोखिम भरे। उन्हें जल्दी विभाजित करें ताकि हर फ़ील्ड एक स्पष्ट तथ्य ही स्टोर करे।

जो इकाइयाँ मिलीं उनसे टेबल बनाएं

एक बार जब आप शीट में वास्तविक दुनिया की चीज़ों के नाम बता सकें, तो हर एक को अपनी तालिका में बदल दें। आपकी स्प्रेडशीट एक बड़े ग्रिड के बजाय छोटे, उद्देश्यपूर्ण सूचियों का समूह बन जाएगी।

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

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

कुछ व्यावहारिक नियम:

• एक ही चीज़ को वर्णित करने वाले और एक ही लाइफसाइकल साझा करने वाले एट्रिब्यूट्स को एक साथ रखें (customer name और customer email)।
• जो चीज़ कई बार दिख सकती है उसे अपनी तालिका में ले जाएं (multiple order items, multiple addresses)।
• अगर एक सेल में सूची है (कॉमा-सेपरेटेड मूल्य, दोहराए कॉलम), तो वह अलग तालिका है।
• अगर दो फ़ील्ड सेट अलग कारणों से बदलते हैं, तो उन्हें अलग रखें (order status बनाम customer contact info)।

फिर कॉलम्स को स्पष्ट और सुसंगत नाम दें। सरल संज्ञाओं को प्राथमिकता दें और "Info" या "Details" जैसे अस्पष्ट लेबल से बचें।

समय के साथ स्थिर रहने वाली कीज़ चुनें

हर तालिका के लिए जल्द से जल्द एक प्राथमिक कुंजी चुनें। एक अच्छी की उबाऊ होती है: यह कभी नहीं बदलती, हमेशा मौजूद रहती है, और एक पंक्ति को ही पहचानती है।

नेचुरल कीज़ (वास्तविक दुनिया के मान) काम कर सकती हैं, पर तभी जब वे वास्तव में स्थिर हों। SKU अक्सर अच्छी नेचुरल की होती है क्योंकि उसे स्थायी माना जाता है। ईमेल पते स्थिर लगते हैं, पर लोग ईमेल बदलते हैं, इनबॉक्स साझा करते हैं, और डुप्लीकेट बन जाते हैं। नाम, फोन नंबर, और पते बदलते हैं और यूनिक की गारंटी नहीं होती।

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

सरल कुंजी नियम:

• जब वास्तविक दुनिया पहचानकर्ता बदल सकती है, गायब हो सकती है, या पुन: उपयोग हो सकती है तो ऑटो ID का उपयोग करें।
• नेचुरल की तभी उपयोग करें जब आप इसे नियंत्रित करते हों और यह स्थायी के लिए डिज़ाइन की गई हो (उदा., SKU)।
• फ़ील्ड्स को यूनिक तब ही मार्क करें जब डुप्लीकेट गलत हों।
• NULL तभी अनुमति दें जब “अनजान” एक वैध स्थिति हो; अन्यथा वैल्यू आवश्यक रखें।
• लिखकर रखें कि “unique” का अर्थ क्या है (तालिका एक्सक्लूसिव, कंपनी-विशेष, या समय-सीमा पर)।

उदाहरण: Contacts तालिका में contact_id को प्राथमिक कुंजी के रूप में उपयोग करें। email को तब ही यूनिक रखें जब नियम यह कहे कि एक contact = एक email। phone को खाली रहने दें क्योंकि हर किसी के पास यह साझा नहीं होता।

अनुमान लगाए बिना रिश्तों को मैप करें

अधिकांश गलतियाँ इस बात के अनुमान लगाने से आती हैं कि चीज़ें कैसे संबंधित हैं। एक सरल नियम अपनाएँ: अगर एक पंक्ति कई चीज़ों की “मालिक” है, तो वह one-to-many है। विदेशी कुंजी (foreign key) "many" साइड पर रखें।

उदाहरण: एक Customer के कई Orders हो सकते हैं। Orders तालिका में customer_id स्टोर होना चाहिए। अगर आप Customers में ऑर्डर नंबरों की कॉमा-लिस्ट रखें तो जल्दी डुप्लीकेट और गुम डेटा दिखेगा।

Many-to-many स्प्रेडशीट का आम जाल है। अगर एक Order में कई Products हो सकते हैं और एक Product कई Orders में दिख सकता है, तो आपको एक जॉइन टेबल चाहिए (अक्सर line items कहलाती है)। इसमें आमतौर पर order_id, product_id, और quantity व उस समय की कीमत जैसी फ़ील्ड्स होंगी।

One-to-one रिश्ते दुर्लभ हैं। ये तब समझ में आते हैं जब अतिरिक्त डेटा वैकल्पिक हो या गोपनीयता/प्रदर्शन के लिए अलग रखा गया हो (उदा., User और UserProfile)। जब आप सिर्फ इसलिए तालिका विभाजित कर दें क्योंकि शीट में दो टैब थे तब यह चेतावनी संकेत है।

इतिहास के लिए अलग संरचना चाहिए। अगर मान समय के साथ बदल सकते हैं (status, price, address), तो एकल कॉलम ओवरराइट करने से बचें। बदलावों को इतिहास तालिका में पंक्तियों के रूप में रखें ताकि आप पूछ सकें "उस तारीख़ पर क्या सच्चा था?"।

विरोधाभास रोकने के लिए पर्याप्त नार्मलाइज़ करें

सरल नियम: एक तथ्य एक ही जगह स्टोर करें। अगर एक ग्राहक का फ़ोन पाँच पंक्तियों में है, तो कोई चार को अपडेट करेगा और पाँचवीं छूट जाएगी।

नार्मलाइज़ेशन को सरल शब्दों में:

1NF, 2NF, 3NF व्यावहारिक रूप में

पहला नार्मल फॉर्म (1NF) मतलब हर सेल एक मान रखे। अगर कोई कॉलम "red, blue, green" या "SKU1|SKU2|SKU3" रखता है, तो वह छिपी हुई सूची है। इसे संबंधित तालिका में पंक्तियों में तोड़ें।

दूसरा नार्मल फॉर्म (2NF) अक्सर line items में दिखता है। अगर आपकी OrderItems की कुंजी (OrderID, ProductID) है, तो CustomerName जैसी फ़ील्ड वहाँ नहीं होनी चाहिए। वे ऑर्डर पर निर्भर करते हैं, न कि उत्पाद पर।

तीसरा नार्मल फॉर्म (3NF) मतलब नॉन-की फ़ील्ड्स अन्य नॉन-की फ़ील्ड्स पर निर्भर नहीं होनी चाहिए। उदाहरण: अगर आप ZipCode और City दोनों स्टोर करते हैं और City ZipCode से निर्धारित होता है, तो आप मिसमैच का जोखिम उठाते हैं।

एक त्वरित सेल्फ-चेक:

• क्या वही मान कई जगह संपादित हो सकता है?
• क्या एक बदलाव आपको कई अन्य पंक्तियों को अपडेट करने के लिए मजबूर करेगा?
• क्या आप किसी ID से व्युत्पन्न लेबल्स स्टोर कर रहे हैं?
• क्या टोटल्स उन कच्ची पंक्तियों के पास स्टोर किए गए हैं जो उन्हें बनाते हैं?

कब डीनॉर्मलाइज़ करना ठीक है

डीनॉर्मलाइज़ खासकर read-heavy रिपोर्टिंग के लिए ठीक है, और उसे सुरक्षित तरीके से करें: रिपोर्ट तालिका को एक कॉपी मानें जिसे आप पुनर्निर्मित कर सकते हैं। सामान्य तालिकाएँ स्रोत सच्चाई बनी रहें।

उत्पन्न मानों जैसे टोटल्स, बैलेंस, और स्टेटस के लिए उन्हें डुप्लिकेट न करें जब तक कि आपके पास फिर से गणना करने का स्पष्ट नियम न हो। व्यावहारिक दृष्टिकोण: कच्चे लेनदेन स्टोर करें, क्वेरियों में टोटल्स निकालें, और केवल प्रदर्शन की ज़रूरत पर टोटल्स कैश करें।

सामान्य मॉडलिंग जाल जो भविष्य में सफ़ाई बनाते हैं

अधिकांश "शीट में काम किया" वाली समस्याएँ टूल की नहीं बल्कि अर्थ की वजह से आती हैं। लक्ष्य यह है कि हर पंक्ति एक स्पष्ट बात कहे, हर बार एक ही तरह।

सामान्य जाल:

• नामों का उपयोग ID के रूप में करना। "John Smith" यूनिक पहचानकर्ता नहीं है, और नाम बदलते हैं। जनरेटेड ID का उपयोग करें (या सत्यापित ईमेल/फोन), और डिस्प्ले नाम को लेबल मानें।
• लिस्ट्स को एक सेल में पैक करना। यह सरल दिखता है, पर खोज, वैलिडेशन, और रिपोर्टिंग तो टूट जाती है। लिस्ट संबंधित तालिका में होनी चाहिए।
• वर्तमान स्थिति को इतिहास के साथ मिलाना। एक Status कॉलम दोनों_latest स्थिति और कैसे बदला इसका इतिहास नहीं बता सकता। अगर समय मायने रखता है तो स्टेटस चेंजेज़ को टाइमस्टैम्प के साथ इवेंट्स के रूप में स्टोर करें।
• एक तालिका को कई अर्थों के लिए ओवरलोड करना। एक Contacts शीट जिसमें customers, vendors, और employees शामिल हैं अक्सर ऐसे फ़ील्ड्स बनाती है जो केवल कुछ पंक्तियों पर लागू होते हैं। रोल के अनुसार विभाजित करें, या एक साझा Person तालिका रखें और रोल-विशेष तालिकाएँ जोड़ें।
• जरूरी बनाम वैकल्पिक फ़ील्ड्स को अनदेखा करना। अगर प्रमुख फ़ील्ड्स खाली हो सकते हैं, तो आपको ऐसी पंक्तियाँ मिलेंगी जो ठीक से जुड़ नहीं सकतीं। पहले यह तय करें कि क्या आवश्यक है और उसे लागू करें।

अगर आपकी Orders तालिका में कॉलम जैसे Item 1, Item 2, Item 3 हैं, तो आप एक रिपीटिंग ग्रुप देख रहे हैं। Orders तालिका और OrderItems तालिका की योजना बनाएं।

स्कीमा लॉक करने से पहले त्वरित चेकलिस्ट

स्कीमा को लॉक करने से पहले स्पष्टता के लिए अंतिम पास करें। अधिकांश बाद की डेटाबेस पीड़ा छोटी शॉर्टकट्स से आती है जो शुरू में harmless लगे थे।

पूछिए कि क्या हर तालिका एक सरल प्रश्न का उत्तर देती है। “Customers” का मतलब ग्राहकों से होना चाहिए, न कि ग्राहकों के साथ उनका नवीनतम ऑर्डर और कॉल नोट्स भी। अगर आप तालिका को एक छोटे वाक्य में नहीं बता सकते, तो वह मिलीजुली चीज़ है।

अंतिम जाँच:

• क्या आप उस कॉलम (या कॉलम सेट) की ओर इशारा कर सकते हैं जो हर पंक्ति को यूनिक रूप से पहचानता है, भले ही नाम बदल जाएँ?
• क्या किसी सेल में एक से अधिक मान हैं (कॉमा-सेपरेटेड टैग्स, कई ईमेल, Item1/Item2 कॉलम)? यदि हाँ, तो उन्हें चाइल्ड तालिका में विभाजित करें।
• क्या हर रिश्ते को जानबूझकर विदेशी कुंजी के रूप में स्टोर किया गया है? कई-टू-कई के लिए क्या जॉइन टेबल है?
• क्या महत्वपूर्ण फ़ील्ड्स के नियम हैं (प्रत्याशित जहां मिसिंग डेटा प्रक्रिया को तोड़ता है, यूनिक जहां डुप्लीकेट हानिकारक होगा)?
• क्या आप किसी तथ्य (customer address, product price, employee role) को एक ही जगह में ठीक कर सकते हैं?

रियलिटी टेस्ट: कल्पना कीजिए कोई व्यक्ति एक ही ग्राहक को हल्का फरक स्पेलिंग के साथ दो बार दर्ज करता है। अगर आपका स्कीमा इसे आसान बनाता है, तो बेहतर की या यूनिकनेस नियम जोड़ें।

उदाहरण: सेल्स ट्रैकर शीट को साफ तालिकाओं में बदलना

मान लीजिए एक सेल्स ट्रैकर जहाँ हर पंक्ति एक deal है। इसमें कॉलम हैं: Customer Name, Customer Email, Deal Amount, Stage, Close Date, Products (कॉमा-सेपरेटेड सूची), और Notes (कभी-कभी एक सेल में कई नोट्स)।

वह एक पंक्ति दो रिपीटिंग ग्रुप्स छिपाती है: products (एक deal में कई products हो सकते हैं) और notes (एक deal में कई नोट्स हो सकते हैं)। यही वह जगह है जहाँ रूपांतरण अक्सर गलत होते हैं, क्योंकि सेल के अंदर लिस्ट क्वेरी करना कठिन और विरोधाभासी बनाना आसान होता है।

एक साफ "बाद में" मॉडल जो काम के व्यवहार से मेल खाता है:

• Customers (CustomerId, Name, Email)
• Deals (DealId, CustomerId, Amount, Stage, CloseDate)
• Products (ProductId, Name, SKU)
• DealProducts (DealId, ProductId, Quantity, UnitPrice)
• DealNotes (NoteId, DealId, NoteText, CreatedAt)

CustomerId, DealId, और ProductId स्थिर पहचानकर्ता हैं। DealProducts many-to-many संबंध का समाधान करता है: एक deal कई products रख सकता है, और एक product कई deals में आ सकता है। DealNotes नोट्स को अलग रखता है ताकि आप "Note 1, Note 2, Note 3" जैसे कॉलमों से बच सकें।

मॉडलिंग से पहले, “revenue by product” जैसी रिपोर्ट के लिए स्ट्रिंग्स को स्प्लिट करना और उम्मीद करना पड़ता था कि लोग नामों को सुसंगत टाइप करें। मॉडल के बाद यह DealProducts को Deals और Products के साथ जॉइन करने वाली सीधे क्वेरी बन जाती है।

अगले कदम: स्कीमा से काम करने वाले ऐप में जाएँ

एक बार जब आपका स्कीमा पेपर पर सही दिखे, तो इसे असली डेटाबेस में डालें और असली डेटा के साथ टेस्ट करें। सब कुछ एक बार में इम्पोर्ट मत करें। पहले एक छोटा बैच लोड करें, जो टूटे उसे ठीक करें, फिर दोहराएँ।

जोखिम कम रखने का व्यावहारिक क्रम:

• तालिकाएँ और रिश्ते बनाइए।
• 50 से 200 पंक्तियाँ इम्पोर्ट करें, टोटल्स सत्यापित करें, और रेकॉर्ड्स स्पॉट-चेक करें।
• मैपिंग समस्याओं (गलत कॉलम, गुम IDs, डुप्लीकेट) को ठीक करें, फिर फिर से इम्पोर्ट करें।
• जब यह स्थिर हो जाए तो बाकी लोड करें।

जल्दी ही वैलिडेशन नियम जोड़ें ताकि पुराने गंदे शीट-आदतें वापस न आएँ। आवश्यक फ़ील्ड्स को वास्तव में आवश्यक बनाएं, अनुमत मान सीमित करें (जैसे status), फॉर्मैट्स वैलिडेट करें (तिथियाँ और ईमेल), और विदेशी कुंजियाँ उपयोग करें ताकि आप किसी ऐसे ग्राहक के लिए ऑर्डर न बना सकें जो मौजूद ही नहीं है।

फिर शीट को अपडेट के लिए बंद कर दें। जब लोगों के पास सरल फॉर्म और स्पष्ट वर्कफ़्लो हों तो आपके डेटा की सुरक्षा बहुत आसान हो जाती है।

यदि आप बिना कोड लिखे स्कीमा को काम करने वाले आंतरिक टूल में बदलना चाहते हैं, तो AppMaster (appmaster.io) मदद कर सकता है: आप तालिकाएँ और रिश्ते विज़ुअली मॉडल करते हैं, फिर उसी मॉडल से प्रोडक्शन-रेडी बैकएंड, वेब ऐप, और नेटिव मोबाइल ऐप जेनरेट कर सकते हैं।