मॉडर्न बॅकएंड वर्कमध्ये SQL डेटाबेस

बऱ्याच ॲप्समध्ये डेटा असतो त्यांनी ठेवावा. स्टोअर ॲपला खाती, आयटम, ऑर्डर आणि पेमेंटची आवश्यकता असते. बँक ॲपला हस्तांतरण आणि खाते तपशील आवश्यक आहेत. क्लिनिकला रुग्णाच्या फाइल्स आणि भेटीच्या तारखांची आवश्यकता असते. सामग्री पोस्ट करणाऱ्या साइटला वापरकर्ते, पोस्ट, नोट्स आणि प्रकाशन सेटिंग्जची आवश्यकता असते. जरी UI नवीन फ्रंटएंड सेटअपसह बनविला गेला असला तरीही, जरी बॅकएंड कंटेनरमध्ये किंवा क्लाउड सेवांवर चालत असला तरीही, मुख्य गरज सारखीच राहते: डेटा जतन करणे, क्रमवारी लावणे, आणणे आणि सुरक्षित ठेवणे आवश्यक आहे.

बर्याच वर्षांपासून, SQL डेटाबेस हे कार्य हाताळण्याचा एक सामान्य मार्ग आहे. SQL म्हणजे स्ट्रक्चर्ड क्वेरी लँग्वेज. रिलेशनल डेटाबेस सिस्टमशी बोलण्यासाठी ही भाषा वापरली जाते. या दृष्टिकोनासह, डेटाला एक मोठा ब्लॉब मानला जात नाही.

हे पंक्ती आणि स्तंभांसह टेबलमध्ये जाते. सारण्या एकमेकांशी दुवा साधू शकतात, त्यामुळे एका प्रकारचा डेटा दुसऱ्याशी कसा कनेक्ट होतो हे ॲप दाखवू शकते. हे डिझाइन आजच्या बॅकएंड सिस्टममध्ये अजूनही बसते. क्लाउड टूल्स, मायक्रोसर्व्हिसेस, API आणि स्प्लिट-अप सेवांनी बिल्ड प्रक्रिया बदलली आहे. त्यांनी स्पष्ट संरचनेची गरज काढून टाकली नाही. भरवशाच्या व्यवहारातूनही त्यांची सुटका झाली नाही.

एसक्यूएल डेटाबेस परिभाषित करणे

एसक्यूएल डेटाबेस टेबलमध्ये माहिती साठवण्यास मदत करतो. तुम्ही SQL क्वेरी वापरून ती माहिती शोधू आणि फिल्टर करू शकता. या सेटअपमध्ये, ग्राहक आयडी प्रत्येक ऑर्डर योग्य ग्राहकाशी जोडतो. यामुळे, तुम्हाला प्रत्येक ऑर्डर रेकॉर्डमध्ये ग्राहक तपशीलांची पुनरावृत्ती करण्याची गरज नाही.

रिलेशनल डेटाबेस कसे डिझाइन केले जातात याचा हा लिंक मुख्य भाग आहे. रिलेशनल डेटाबेस टूल्सची उदाहरणे आहेत PostgreSQL, MySQL, Microsoft SQL Server, Oracle Database आणि SQLite.

संरचित डेटा महत्त्वाचा आहे

हे डेटा अधिक सुसंगत कसे वर्तन करते. जेव्हा तुम्ही ते डिझाइन करता, तेव्हा तुम्ही ठरवता की प्रत्येक फील्ड काय असावे आणि तेथे कोणत्या प्रकारचे मूल्य बसते.

उदाहरणार्थ, वय फील्ड संख्या म्हणून मानले जाऊ शकते. क्रिएट_एट फील्डला तारीख किंवा टाइमस्टॅम्प म्हणून मानले जाऊ शकते. त्यानंतर, डेटाबेस नियम लागू करू शकतो. जेव्हा एखादे ॲप मोठे आणि अधिक जटिल होते तेव्हा ते खूप मदत करते. कोणतीही योजना नसल्यास, संघ समान कल्पना वेगवेगळ्या स्वरूपात जतन करू शकतात. मग डेटा गोंधळलेला आणि विश्वास ठेवणे कठीण होते.

रिलेशनल डेटाबेस सिस्टम गोष्टी स्वच्छ ठेवण्यासाठी साधने वापरतात. स्कीमा रचना परिभाषित करतात. डेटा प्रकार मर्यादा सेट करतात. बंधने धनादेश जोडतात. संबंध संबंधित डेटा लिंक करतात. त्यामुळे डेटा लेयर यादृच्छिक नोंदींच्या साध्या स्टोरेजपेक्षा अधिक मजबूत विश्वासार्हता प्रदान करते.

सारण्या, पंक्ती आणि स्तंभ

रिलेशनल डेटाबेसमध्ये, मुख्य भाग चित्रित करणे सोपे आहे. टेबलमध्ये एक प्रकारची माहिती असते. पंक्ती ही एक नोंद आहे. स्तंभ ही एक विशेषता आहे.

ऑनलाइन स्टोअरमध्ये, तुम्ही यासाठी टेबल पाहू शकता:

• ग्राहक
• उत्पादने
• ऑर्डर
• ऑर्डर आयटम
• देयके

प्रत्येक टेबलचे स्पष्ट कार्य आहे. यामुळे, डेटाबेस व्यवस्थित ठेवणे सोपे आहे. डेव्हलपर देखील त्यांना दिलेल्या कार्यासाठी आवश्यक तेच खेचू शकतात.

प्राथमिक की: नावे नोंदवा

रिलेशनल डेटाबेसला पंक्ती वेगळे सांगण्यासाठी एक स्वच्छ मार्ग आवश्यक आहे. ते काम प्राथमिक कळावर येते. या सेटअपमध्ये, customer_id प्रत्येक ग्राहकाला चिन्हांकित करतो.

कोणत्याही दोन पंक्तींनी समान ग्राहक_आयडी मूल्य सामायिक करू नये. प्राथमिक की इतर सारण्यांना योग्य रेकॉर्डशी जोडू देतात.

परदेशी की: लिंकिंग टेबल्स

प्रत्येक ऑर्डर एका ग्राहकाची आहे असे म्हणा. ऑर्डर टेबल परदेशी की म्हणून वापरल्या जाणाऱ्या कॉलममध्ये ग्राहकाचा आयडी सेव्ह करू शकतो. तो नियम डेटाबेसला संदर्भित ग्राहक अस्तित्वात असल्यासच ऑर्डर स्वीकारण्यास सांगतो. हे संदर्भात्मक अखंडतेचे समर्थन करते.

या प्रकारच्या लिंकिंगमध्ये रिलेशनल मॉडेल्स चमकतात. लोक डेटा अलग ठेवत नाहीत. ग्राहक ऑर्डर देतो. त्या ऑर्डरमध्ये उत्पादने असतात. पेमेंट ऑर्डरशी जोडले जाते. उत्पादन श्रेणीचे असू शकते. हे दुवे थेट मार्गाने दर्शविण्यासाठी SQL डेटाबेस तयार केले आहेत.

SQL क्वेरी: डेटाबेसमधून उत्तरे मिळवणे

एसक्यूएल हा डेटा खेचण्यासाठी आणि त्याच्यासह कार्य करण्यासाठी कमांडचा संच आहे. तुम्ही विशिष्ट फील्ड विचारण्यासाठी क्वेरी लिहू शकता.

उदाहरणार्थ:

नाव, ईमेल निवडा

ग्राहकांकडून;

ही ओळ डेटाबेसला ग्राहकाचे नाव आणि ईमेल परत पाठवण्यास सांगते. कधीकधी आपल्याला फक्त एक ग्राहक आवश्यक असतो. ती क्वेरी आउटपुटला त्या पंक्तीपर्यंत मर्यादित करते जिथे आयडी 101 शी जुळते.

SQL क्रमवारी, गटबद्ध करणे, फिल्टर करणे आणि बेरीजची गणना करण्यास देखील समर्थन देते. त्यामुळे, ते संघांना ॲप्समध्ये वैशिष्ट्ये तयार करण्यात मदत करते. हे विश्लेषण आणि अहवाल कार्यास देखील समर्थन देते.

SQL सामील: विभक्त सारण्यांमधून माहिती एकत्र करणे

अनेक वास्तविक डेटासेट एकापेक्षा जास्त टेबलमध्ये राहतात. आपण सर्वकाही एका मोठ्या टेबलमध्ये ठेवल्यास, आपण अनेकदा डेटाची पुनरावृत्ती करता. ते नंतर अद्यतने अधिक कठीण करू शकतात.

त्यामुळे सारण्या तार्किक पद्धतीने विभाजित केल्या जातात. एक जोडणी संबंधित तुकडे एकत्र आणते. जेव्हा तुम्हाला एकाच वेळी दोन टेबलमधून डेटा हवा असतो तेव्हा हे असे करते.

उदाहरणार्थ:

ग्राहक निवडा. नाव, ऑर्डर, रक्कम

ग्राहकांकडून

ऑर्डरमध्ये सामील व्हा

ON customers.customer_id = orders customer_id;

हे प्रत्येक ग्राहकाला जुळणाऱ्या ऑर्डरशी लिंक करते.

आपण आउटपुट पाहिल्यास, ते यासारखी मूल्ये सूचीबद्ध करू शकते:

• माया – ₹२,५००
• अर्जुन – ₹१,८००

डेटाबेस दोन्ही सारण्यांमधून वाचतो आणि सामायिक ग्राहक संबंध वापरून परिणाम विलीन करतो.

SQL जॉइन्स तुम्ही अनेकदा पाहता

अनेक विकासक एकापेक्षा जास्त प्रकारचे जॉईन वापरतात.

येथे सामान्य आहेत.

इनर जॉईन

जेव्हा दोन्ही सारण्या जुळतात तेव्हाच पंक्ती ठेवते.

डावीकडे सामील व्हा

डाव्या सारणीतून प्रत्येक पंक्ती दाखवते.

हे शक्य असेल तेव्हा उजव्या टेबलमधून जुळणाऱ्या पंक्ती जोडते.

उजवीकडे सामील व्हा

उजव्या टेबलमधून प्रत्येक पंक्ती दाखवते.

हे शक्य असेल तेव्हा डाव्या सारणीतून जुळणाऱ्या पंक्ती जोडते.

पूर्ण बाह्य सामील व्हा

दोन्ही बाजूंना जुळत नसलेल्या जुळण्या आणि पंक्ती दाखवते. डेटाबेस समर्थित असेल तरच हे कार्य करते.

बॅकएंड कामासाठी ज्ञान बाबींमध्ये सामील व्हा.

वास्तविक प्रणालींमध्ये, डेटा क्वचितच एका टेबलमध्ये ठेवला जातो.

व्यवहार आणि डेटा सुरक्षा

SQL डेटाबेस एका कारणासाठी वापरले जातात. ते व्यवहार करू शकतात. एक व्यवहार अनेक क्रियांना एक युनिट मानतो. ॲपमधील पेमेंट फ्लोबद्दल विचार करा.

सिस्टमला याची आवश्यकता असू शकते:

• ऑर्डर करा
• पेमेंट रेकॉर्ड जतन करा
• उपलब्ध स्टॉक कमी करा
• ऑर्डर स्थिती बदला

आता कल्पना करा की एक पाऊल चुकीचे आहे. पेमेंट पूर्ण होऊ शकते, परंतु स्टॉक बदलणे अयशस्वी होते. ते विवादित डेटासह ॲप सोडू शकते. व्यवहारांसह, संबंधित चरण एकत्रितपणे हाताळले जातात. सर्व पायऱ्या पूर्ण झाल्यास, सिस्टम कार्य करेल. एक पाऊल अयशस्वी झाल्यास, सिस्टम सर्वकाही परत आणते.

रिलेशनल सिस्टम्समध्ये ACID व्यवहार

जेव्हा लोक व्यवहारांबद्दल बोलतात तेव्हा ते सहसा चार ACID वैशिष्ट्यांसह प्रारंभ करतात.

ॲटॉमिसिटी म्हणजे व्यवहारातील काम एकतर पूर्ण होते किंवा होत नाही. सुसंगतता म्हणजे डेटाबेस त्याच्या नियमांमध्ये राहतो.

पृथक्करण म्हणजे एकाच वेळी चालणारे दोन व्यवहार त्यांचे परिणाम एकत्र करू नयेत.

टिकाऊपणाचा अर्थ असा आहे की कमिट केल्यानंतर, अयशस्वी झाले तरीही अद्यतन तेथेच असेल.

जेव्हा तुटलेल्या किंवा अर्धवट झालेल्या व्यवहारामुळे खरे नुकसान होऊ शकते तेव्हा हे खूप महत्त्वाचे आहे. वित्त ॲप्स ही एक केस आहे. ऑर्डर ट्रॅकिंग आणखी एक आहे.

इन्व्हेंटरी सिस्टम येथे देखील बसते. आरक्षण कार्यप्रवाह देखील या कल्पनेवर अवलंबून असतात.

SQL डेटाबेस आणि बॅकएंड कोड त्यांचा कसा वापर करतो

अनेक ॲप्स डेटाबेसशी थेट बोलत नाहीत.

त्याऐवजी, ते सेवा आणि API द्वारे जातात.

एक साधा मार्ग यासारखा दिसतो:

मोबाइल ॲप API ला कॉल पाठवते.

API ते बॅकएंड सेवेकडे देते.

बॅकएंड नंतर SQL डेटाबेसशी बोलतो.

उदाहरणार्थ, एखादी व्यक्ती ॲप उघडते आणि मागील ऑर्डर विचारते. बॅकएंड वापरकर्ता कोण आहे ते तपासते. मग ते आवश्यक डेटाबेस क्वेरी चालवते.

त्यानंतर, ते आउटपुटचे स्वरूपन करते आणि API डेटा म्हणून परत पाठवते. बऱ्याच प्रकरणांमध्ये, ॲप वापरणाऱ्या व्यक्तीपासून डेटाबेस लपलेला वाटतो. तरीही, ॲप कसे कार्य करते याचा हा एक महत्त्वाचा भाग आहे.

SQL आणि क्लाउड ॲप्स

SQL जुन्या-शैलीच्या सर्व्हरशी जोडलेले म्हणून पाहिले जात असे. ते दृश्य आता टिकत नाही. आज, क्लाउड प्रदाते तुमच्यासाठी व्यवस्थापित रिलेशनल डेटाबेस सेवा चालवतात. ते खूप नियमित कामाची काळजी घेतात.

टीम अजूनही कंटेनर, सर्व्हरलेस सेटअप किंवा मायक्रो सर्व्हिसेससह ॲप्स पाठवू शकतात. ते ते करू शकतात आणि रिलेशनल डेटाबेस वापरत राहू शकतात.

क्लाउड SQL सेवांमध्ये सहसा हे समाविष्ट असते:

• स्वयंचलित बॅकअप
• प्रतिकृती
• देखरेख
• स्केलिंग पर्याय
• उच्च उपलब्धता
• सुरक्षा नियंत्रणे

त्यामुळे टीम रिलेशनल डेटा मॉडेल ठेवू शकतात.

त्यांना प्रत्येक डेटाबेस सर्व्हर हाताने चालवावा लागत नाही.

एसक्यूएल इनसाइड मायक्रोसर्व्हिसेस

मायक्रोसर्व्हिसेस डेटा कसा तयार करावा याबद्दल कठोर प्रश्न उपस्थित करतात. एक कल्पना सोपी आहे: प्रत्येक सेवेचा स्वतःचा डेटा असावा. सेवेने इतर सेवांशी संबंधित टेबल्स मुक्तपणे संपादित करू नयेत.

याचा अर्थ SQL निघून जातो असा नाही. पोस्टग्रेएसक्यूएल, मायएसक्यूएल किंवा अन्य रिलेशनल डेटाबेसवर एकल मायक्रोसर्व्हिस अजूनही चालू शकते.

उदाहरणार्थ:

ऑर्डर सेवा ऑर्डर डेटाबेस वापरते.

ग्राहक सेवा ग्राहक डेटाबेस वापरते.

इन्व्हेंटरी सर्व्हिस इन्व्हेंटरी डेटाबेस वापरते.

हे सेवेनुसार कर्तव्ये विभाजित करते. प्रत्येक सेवा त्याला आवश्यक असलेले डेटाबेस टूल निवडते. कठिण भाग म्हणजे सर्व सेवांमध्ये लाइन अप करण्यासाठी संबंधित डेटा मिळवणे.

अहवाल आणि विश्लेषणासाठी SQL

एसक्यूएल हे दैनंदिन व्यवहार चालवणाऱ्या सॉफ्टवेअरसाठीच नाही. कंपन्या काम करत असताना भरपूर संरचित डेटा साठवतात. नेते सहसा असे प्रश्न विचारतात:

कोणत्या वस्तू सर्वात जास्त पैसे आणतात?

कोणते क्षेत्र सर्वाधिक कमाई करतात?

दर महिन्याला किती दुकानदार परत येतात? ठराविक ऑर्डर आकार काय आहे?

एकाच ट्रिपमध्ये कोणत्या वस्तू खरेदी केल्या जातात?

SQL हे सिग्नल गोळा करू शकते आणि त्यांचा सारांश देऊ शकते.

उदाहरणार्थ:

श्रेणी निवडा, SUM(रक्कम)

विक्री पासून

श्रेणीनुसार गट;

यासारख्या प्रश्नांमुळे साध्या पंक्ती स्पष्ट व्यवसाय दृश्यांमध्ये बदलतात. त्यामुळे एसक्यूएल दैनंदिन सिस्टीम आणि रिपोर्टिंग काम दोन्हीसाठी फिट आहे.

डेटा प्लॅटफॉर्ममध्ये SQL

बऱ्याच नवीन सेटअप्समध्ये दोन प्रकारच्या सिस्टीम मिसळतात. एक भाग व्यवहार हाताळतो. दुसरा भाग मोठ्या प्रमाणावर विश्लेषणास समर्थन देतो. एक संघ रोजच्या कामासाठी रिलेशनल डेटाबेस चालवू शकतो.

ते डेटा वेअरहाऊस किंवा लेकहाऊसमध्ये डेटा कॉपी किंवा प्रवाहित करू शकतात. त्या विभाजनासह, मोठ्या विश्लेषण क्वेरी मुख्य ॲपला जास्त धीमा करत नाहीत. SQL अजूनही या विश्लेषण साधनांमध्ये भूमिका बजावते.

म्हणूनच SQL आजच्या डेटा स्टॅकमध्ये दिसत आहे. हे केवळ अनुप्रयोग विकासाच्या जुन्या शैलीशी जोडलेले नाही.

निष्कर्ष

बॅकएंडचे काम पूर्वीपेक्षा वेगळे दिसते. क्लाउड सेटअप नियमित आहेत. कार्यसंघ नेटवर्कवर API आणि सेवा पाठवतात. ॲप्स अनेकदा कंटेनरमध्ये चालतात. काही गट सिस्टमच्या भागांसाठी सर्व्हरलेस निवडतात. जेव्हा ते अर्थपूर्ण असेल तेव्हा इतर AI वैशिष्ट्ये जोडतात.

या बदलांसह, डेटाची आवश्यकता दूर होत नाही. बरेच ॲप्स अजूनही डेटा व्यवस्थित ठेवतात. ते अजूनही फील्डमधील मूल्ये आणि पंक्तींमध्ये रेकॉर्ड जतन करतात. ते अजूनही एका विक्रमाशी दुस-या विक्रमाशी बरोबरी करतात.

त्यांना अजूनही अशा व्यवहारांची गरज आहे जे सिस्टम गडबड किंवा ट्रॅफिक जंप झाल्यावर खंडित होत नाहीत. त्यांना जतन केलेल्या डेटाच्या विरूद्ध काळजीपूर्वक प्रश्न चालवणे देखील आवश्यक आहे. आणि ते अजूनही वापरकर्ते आणि कर्मचाऱ्यांसाठी अहवाल आणि सारांश तयार करतात.

म्हणूनच SQL डेटाबेस त्यांची जागा ठेवतात. SQL सह, तुम्हाला टेबल आणि स्पष्ट डेटा लेआउट मिळतात. तुम्ही पंक्तींमधील दुवे सेट करू शकता. तुम्ही वेगळ्या सारण्यांमधून डेटामध्ये सामील होऊ शकता. तुम्ही व्यवहार करू शकता. तुम्ही मर्यादांसारखे नियम जोडू शकता. जेव्हा तुम्हाला मूलभूत वाचनांपेक्षा अधिक आवश्यक असेल तेव्हा तुम्ही तपशीलवार क्वेरी देखील करू शकता.

एसक्यूएल प्रत्येक वर्कलोडसाठी योग्य नाही. काही संघ NoSQL सह चांगले काम करतात. काहींना मॅच सर्च टूल्सची आवश्यकता असते. इतर प्रकरणांमध्ये विशिष्ट कार्यांसाठी किंवा अनेक नोड्समध्ये पसरलेल्या डेटासाठी बनवलेल्या साधनांची मागणी केली जाते. बरेच आधुनिक स्टॅक अनेक डेटा टूल्स वापरतात.

ते प्रत्येक समस्येला एकाच डेटाबेसमध्ये आणण्याचे टाळतात. तरीही, बॅक-एंड कामासाठी SQL हे मुख्य कौशल्य आहे. तुम्ही एक छोटी साइट किंवा मोठा क्लाउड प्लॅटफॉर्म तयार केल्यास, तुम्ही टेबल्स वापराल. तुम्ही लिंक केलेल्या डेटासह कार्य कराल. तुम्ही जॉईन लिहाल. व्यवहार सांभाळाल. तुम्ही अनुक्रमणिका आणि क्वेरी कशा केल्या जातात याबद्दल देखील विचार कराल.

वेळ निघून गेल्यावर साधने बदलू शकतात. मुख्य ध्येय नाही. ॲप्समध्ये ते विश्वास ठेवू शकतील असा डेटा असणे आवश्यक आहे. त्यांना द्रुत वाचन आणि स्थिर कामगिरी आवश्यक आहे. प्रणाली मोठी होत असताना त्यांना सातत्य आवश्यक आहे. SQL डेटाबेस येथे चांगले काम करतात, म्हणून ते एक ठोस आधार राहतात.

(स्त्रोत)