स्प्रेडशीट्स - एक्सेल, गूगल शीट्स, या किसी अन्य नाम से एक शीट - वास्तव में अच्छे और शक्तिशाली उपकरण हैं। लेकिन फिर, डेटाबेस भी हैं। आपको स्प्रेडशीट के साथ कब रहना चाहिए? आपको डेटाबेस में कब जाना चाहिए?
यह मेरे पिछले लेख "स्प्रेडशीट बनाम डेटाबेस:क्या यह स्विच करने का समय है?" की निरंतरता है। जहां हमने ढेर सारे डेटा को व्यवस्थित करने के लिए स्प्रेडशीट का उपयोग करने के सबसे सामान्य नुकसानों पर चर्चा की है। इस लेख में, हम जानेंगे कि कैसे एक डेटाबेस उन समस्याओं को हल करता है।
डेटा को व्यवस्थित करने के लिए डेटाबेस का उपयोग करना
मेरा आदर्श वाक्य है "अपनी आवश्यकताओं के लिए उपयुक्त तकनीक का उपयोग करें"। यदि आप अपना व्यवसाय शीट के माध्यम से चला सकते हैं, तो बढ़िया! यदि आपको एक साधारण डेटाबेस की आवश्यकता है, तो MS Access एक बुरा विकल्प नहीं है। लेकिन अगर ये उत्पाद आपके लिए काम नहीं कर रहे हैं, तो आपको शायद एक अनुकूलित डेटाबेस और एक वेब एप्लिकेशन की आवश्यकता होगी। डेटाबेस आपके डेटा को स्टोर करेगा; वेब ऐप डेटाबेस के साथ इंटरैक्ट करने और डेटा स्तर के साथ संचार करने का एक उपयोगकर्ता के अनुकूल तरीका होगा।
हमारा काल्पनिक सेवा व्यवसाय बहुत जटिल नहीं था, इसलिए हम इसे काफी सरल डेटा मॉडल का उपयोग करके संचालित कर सकते थे। यदि आप नीचे दी गई छवि को देखते हैं, तो आप देखेंगे कि हमें जो कुछ भी चाहिए वह केवल पांच तालिकाओं में संग्रहीत है:client_type , client , service , replacement , और has_service ।
डेटाबेस डिज़ाइन का एक प्रमुख नियम है संबंधित वास्तविक-विश्व डेटा को एक ही स्थान पर रखना . इस मामले में, हम अपने सभी client ग्राहक तालिका में डेटा। इस तरह, हम एक ही डेटा को कई स्थानों पर संग्रहीत करने से बचेंगे (खराब प्रकार की अतिरेक का उल्लेख पहले किया गया था)। यदि हम क्लाइंट से संबंधित कुछ भी बदलते हैं, तो हम इसे इस तालिका में केवल एक बार करेंगे। यह डेटा की गुणवत्ता में बहुत सुधार करेगा और प्रदर्शन के लिए अच्छा होगा।
अगली तालिका जिसमें वास्तविक दुनिया का डेटा है, वह है service टेबल। फिर से, हम अपनी सेवाओं से संबंधित सभी विवरणों को यहां स्टोर कर सकते हैं और हम डेटा में काफी कुशलता से बदलाव कर सकते हैं।
client तालिका और service तालिका वास्तविक दुनिया की इकाइयाँ हैं जो दूसरे के बिना मौजूद हो सकती हैं। हालाँकि, असंबंधित संस्थाओं के साथ एक डेटाबेस बनाना बहुत अधिक समझ में नहीं आता है - यह ग्राहकों के बिना उत्पादों या सेवाओं के बिना खरीदारों के होने जैसा है। इसलिए हम has_service टेबल। यह जानकारी संग्रहीत करने के लिए कि किस क्लाइंट के पास कौन सी सेवा है, हम उस क्लाइंट और सेवा के संदर्भ के रूप में कार्य करने वाली विदेशी कुंजियों का उपयोग करेंगे। ये विदेशी कुंजियाँ सेवा और क्लाइंट तालिकाओं में रिकॉर्ड की ओर इशारा करती हैं। हम इस तालिका में प्रत्येक ग्राहक-सेवा संबंध से संबंधित कोई अतिरिक्त जानकारी भी रख सकते हैं।
client_type तालिका का उपयोग एक शब्दकोश की तरह किया जाता है जो हर संभव प्रकार के क्लाइंट को संग्रहीत करता है। अलग-अलग डिक्शनरी टेबल में अलग-अलग सेगमेंट रखना सबसे अच्छा है (उदाहरण के लिए अगर हमारे पास ग्राहक प्रकार और कर्मचारी भूमिका प्रकार थे, तो हम उन्हें अलग-अलग टेबल में स्टोर करेंगे)। हालांकि, हमें केवल एक टेबल की जरूरत है क्योंकि यह एक साधारण मॉडल है।
हमारे मॉडल में अंतिम तालिका है replacement टेबल। हम इसका उपयोग दो सेवाओं को जोड़ने के लिए करेंगे:एक ऐसी सेवा जिसे हम बदलना चाहते हैं और दूसरी सेवा। यह हमें मौजूदा सेवाओं के लिए ग्राहकों के प्रतिस्थापन की पेशकश करने की सुविधा देता है (जैसे कि एक मोबाइल कॉलिंग योजना से दूसरे में बदलना)।
डेटाबेस लाभ
स्प्रैडशीट की तुलना में डेटाबेस स्थापित करने के लिए अधिक जटिल हैं, लेकिन यह वास्तव में उन्हें डेटा अखंडता और सुरक्षा के मामले में कुछ महत्वपूर्ण लाभ देता है:
कुंजी और बाधाएं
डेटाबेस में अंतर्निहित नियम और नियंत्रण होते हैं, जो यदि ठीक से उपयोग किए जाते हैं, तो अधिकांश डेटा गुणवत्ता और प्रदर्शन संबंधी समस्याओं को रोका जा सकता है। प्राथमिक कुंजी (कॉलम जो तालिका में प्रत्येक रिकॉर्ड की विशिष्ट रूप से पहचान करते हैं) और विदेशी कुंजी (कॉलम जो किसी अन्य तालिका में रिकॉर्ड को संदर्भित करते हैं) डेटा सुरक्षा के लिए महत्वपूर्ण हैं, लेकिन वैकल्पिक या अद्वितीय कुंजियों को परिभाषित करना (जिसमें तालिका में प्रत्येक रिकॉर्ड के लिए अद्वितीय डेटा होता है) ) भी बहुत मददगार है।
रिलेशनल डेटाबेस में, कुंजियाँ विभिन्न तालिकाओं के डेटा से संबंधित होती हैं। तालिका की प्राथमिक कुंजी हमेशा अद्वितीय होती है, जबकि एक विदेशी कुंजी किसी अन्य तालिका से प्राथमिक कुंजी का संदर्भ देती है। वह संदर्भ इन दो तालिकाओं के डेटा से संबंधित है (उदा. has_service तालिका ग्राहक डेटा को उनकी सेवाओं से संबंधित करती है)। यदि हम किसी अन्य तालिका में संदर्भित प्राथमिक कुंजी को हटाने वाले हैं तो यह हमें चेतावनी भी देगा। यह हमें उन रिकॉर्ड को हटाने से रोकेगा जिनकी अभी भी किसी अन्य तालिका में आवश्यकता है (संदर्भ के रूप में)।
बाधाएं उस प्रकार के डेटा को परिभाषित करती हैं जिसे किसी फ़ील्ड में दर्ज किया जा सकता है। हम निर्दिष्ट कर सकते हैं कि डेटा का मान होना चाहिए (नल नहीं), फ़ोन नंबरों के लिए एक प्रारूप परिभाषित करें, केवल अक्षर हों, और इसी तरह। इसका मतलब है कि हम किसी क्षेत्र में गलत प्रकार के डेटा दर्ज करने वाले लोगों की डेटा समस्याओं से बच सकते हैं।
सुरक्षा और अनुमतियां
एक और बहुत महत्वपूर्ण डेटाबेस विशेषता है आपके डेटा तक पहुंच को नियंत्रित करना . यह आपको न केवल यह निर्धारित करने की क्षमता देता है कि कौन आपके डेटाबेस तक पहुंच सकता है बल्कि यह भी नियंत्रित कर सकता है कि वे क्या देख या संशोधित कर सकते हैं। यह डेटा सुरक्षा का एक बड़ा हिस्सा है। उदाहरण के लिए, आप एक उपयोगकर्ता भूमिका परिभाषित कर सकते हैं जो एक कर्मचारी को ग्राहक विवरण बदलने की अनुमति देगा लेकिन सेवा विवरण नहीं। आप ऐसे नियम भी निर्धारित कर सकते हैं जिन पर कर्मचारी डेटा बदल सकते हैं या हटा सकते हैं। यह सुनिश्चित करने के लिए एक अच्छा मानक अभ्यास है कि लोगों के पास केवल उस डेटा तक पहुंच है जिसकी उन्हें अपना काम करने की आवश्यकता है।
बेशक, हम चादरों में इन कार्यात्मकताओं को फिर से बनाने की कोशिश कर सकते हैं (कम से कम किसी तरह से), लेकिन यह निश्चित रूप से "पहिया को फिर से बनाना" होगा।
क्या हम केवल एक स्प्रेडशीट का उपयोग नहीं कर सकते?
बेशक हम कर सकते थे। हम शीट बना सकते हैं जो डेटा मॉडल में उपयोग किए गए समान पैटर्न का पालन करती हैं। इससे कई डेटा समस्याएं हल हो जाएंगी, लेकिन…
शीट में डेटा मॉडल की प्रतिकृति निश्चित रूप से एक आदर्श विकल्प नहीं है। हम उन सभी लाभों को खो देंगे जो डेटाबेस सिस्टम हमें प्रदान करता है, सभी नियम और बाधाएं जो डेटा को "स्वस्थ" रखती हैं, वे सभी चीजें जो आकस्मिक विलोपन और अन्य त्रुटियों को रोकती हैं। हम ऑप्टिमाइज़ेशन से चूक जाते हैं और, यदि डेटासेट काफी बड़ा होता, तो प्रदर्शन प्रभावित होता।
भले ही हमने इसे हल कर लिया हो, डेटा साझा करने के बारे में क्या, उदा। एक ही समय में एक ही शीट का उपयोग करने वाले एकाधिक उपयोगकर्ता हैं? इसके कारण डेटा अखंडता और प्रदर्शन संबंधी समस्याएं क्या होंगी? यह चीजों को सरल रखने के विपरीत होगा।
इसलिए यदि आपको लगता है कि शीट आपकी व्यावसायिक जरूरतों को पूरा नहीं कर सकती हैं, तो आप शायद पहले से ही एक डेटाबेस की ओर बढ़ रहे हैं। यदि आप अपने आप को शीट में संग्रहीत डेटा के साथ अटका हुआ पाते हैं और आप एक डेटाबेस में जाना चाहते हैं, तो आपको यह करना चाहिए:
- एक डेटाबेस मॉडल बनाएं जो आपके डेटा को बेहतर तरीके से संग्रहीत करे।
- पृष्ठभूमि में डेटाबेस के साथ एक एप्लिकेशन बनाएं।
- अपना डेटा साफ़ करें, उसे रूपांतरित करें (यदि आवश्यक हो), और उसे डेटाबेस में आयात करें।
- केवल डेटाबेस के साथ काम करना जारी रखें।
आपको कौन सा चुनना चाहिए - स्प्रेडशीट या डेटाबेस?
आज के लेख में, हमने सीखा है कि कैसे एक डेटाबेस ढेर सारे डेटा को व्यवस्थित करने के लिए शीट्स का उपयोग करने की समस्याओं को हल करता है। मेरी सलाह है कि हमेशा अपनी समस्या के सबसे सरल समाधान के साथ चलें . यदि स्प्रैडशीट ठीक से काम करेगी, तो उनका उपयोग करें। लेकिन अगर आप डेटा-संचालित कंपनी हैं, तो आपको ASAP डेटाबेस का उपयोग करना शुरू कर देना चाहिए। आप अपने डेटा को साफ़ करने और माइग्रेट करने के लिए जितनी देर प्रतीक्षा करेंगे, प्रक्रिया उतनी ही अधिक दर्दनाक होगी।
