प्रोग्रामिंग और डेटाबेस क्वेरी को बंद करना [बंद]

Question

C ++ या Java जैसी ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग भाषाओं के लिए एक सामान्य ट्यूटोरियल पर विचार करें: खातों, आदेशों, वस्तुओं आदि (या अधिक या कम समकक्ष) का प्रतिनिधित्व करने वाली वस्तुओं के साथ एक सरल ऑर्डर प्रोसेसिंग सिस्टम बनाएं। पूर्ण सहज ज्ञान युक्त समझ में आता है, लेकिन डाइनिंग टेबल पर हाथी यह है कि यह वास्तविक नहीं है क्योंकि ये इन-मेमोरी ऑब्जेक्ट हैं; एक वास्तविक प्रणाली में, खाते, आदेश आदि वास्तव में पहली जगह में स्मृति में नहीं रहते हैं , वे एक डेटाबेस में रहते हैं, स्मृति प्रतिनिधित्व केवल एक अल्पकालिक दर्पण के साथ।

आप डेटाबेस से पढ़ने और लिखने के लिए खुद को बहुत सारे कोड लिख सकते हैं, लेकिन यह इतना थकाऊ और त्रुटिपूर्ण है कि कोई भी वास्तव में ऐसा नहीं करता है।

हर कोई एक ORM का उपयोग करके समाप्त होता है, लेकिन वे अपने आप में इतने समस्याग्रस्त हैं कि एक प्रसिद्ध पेपर उन्हें 'हमारे उद्योग का वियतनाम' कहता है।

मुझे नहीं लगता है कि वस्तु और संबंध के बीच एक बेमेल इतनी है कि प्रोग्रामिंग भाषा और डेटाबेस के बीच एक बेमेल के रूप में अलग चीजें हैं जो एक दूसरे के बारे में नहीं जानते हैं । अनुमान: समाधान के लिए एक एकल भाषा है जो प्रोग्रामिंग और डेटाबेस दोनों क्वेरी भाषा है, जिसके बदले में भाषा रनटाइम भी डेटाबेस की आवश्यकता होगी, और JIT संकलक भी क्वेरी ऑप्टिमाइज़र हो।

तो यह है कि मैं इसे देख समस्याओं का सारांश है। मेरा सवाल है, किसी को भी अभी तक है,

1. वास्तव में ऐसी एकीकृत प्रणाली का निर्माण किया

2. कोशिश की लेकिन ऐसी एकीकृत प्रणाली बनाने में असफल रहे

3. आप इस तरह के निर्माण के बारे में कैसे जाएंगे, या क्यों या क्यों नहीं, इस विषय पर पर्याप्त कुछ भी लिखा

4. समस्या को हल करने का एक वैकल्पिक तरीका है?

Comments

एक बार जब आपके पास एक भाषा होती है जो डेटाबेस और कोड को एकजुट करती है, तो आपको एक ऐसी भाषा का आविष्कार करने की आवश्यकता होती है जो डेटाबेस, कोड और HTML को एकीकृत करती है। फिर आपको JSON के साथ एकीकरण करने की आवश्यकता है। फिर आपको पर्ल की तुलना में अधिक अंतरंग तरीके से रेगेक्सप के साथ एकीकरण करने की आवश्यकता है। फिर आपको LDAP (उदाहरण के लिए Microsoft सक्रिय निर्देशिका, हाँ, यह एक डेटाबेस है) जैसे पदानुक्रमित डेटाबेस के साथ एकीकृत करने की आवश्यकता है। तब आपको मानगो या कैसंड्रा जैसे कुंजी-मूल्य डेटाबेस के साथ एकीकरण करने की आवश्यकता है। फिर आपको 3 डी रेंडरिंग आदि के साथ एकजुट होने की जरूरत है। आप एक हथौड़ा-स्पैनर-क्रेन-फावड़ा-पेचकश-

— ब्लोकोरोच

ऐसा लगता है कि आपके प्रस्तावित समाधान अनुप्रयोगों के साथ एक दूरस्थ डेटाबेस तक पहुंचने में असमर्थ होंगे या क्या मैंने आपको गलत समझा? क्योंकि एप्लिकेशन और डेटाबेस दोनों रनटाइम के एक ही उदाहरण का उपयोग करते हैं।

— मोनिका

यह प्रौद्योगिकी के साथ कुछ नहीं करना है, लेकिन डेटासेट के साथ अधिक करना है। मुझे एक बार कोड के एक टुकड़े का अनुकूलन करना पड़ा क्योंकि रेगेक्स को निष्पादित करने में 3 मिनट लग रहे थे। यह पता चला कि ईमेल और ईमेल का जवाब देते समय लोग पूरे संदेशों को उद्धृत कर रहे थे, कभी-कभी 5mb तक बढ़ सकता है। केवल 5mb रेगेक्स चोक हो सकता है। इसलिए SQL काफी तेज है। हमें

— बजे

यह भी इंगित करने के लायक है कि आपके एप्लिकेशन के लक्ष्यों के आधार पर, RDBMS के भीतर "ऑप्टिमाइज़" का अर्थ क्या अलग है। आप क्या सूचकांक करते हैं? कब? कैसे? इंडेक्स में आप किन क्षेत्रों को शामिल करते हैं? क्या आप उच्च लिखने की गति या उच्च क्वेरी गति या अधिकतम अखंडता को अनुकूलित करते हैं? उस परंपरा को मूल भाषा का हिस्सा बनाने से कोई बदलाव नहीं आएगा, अगर कुछ भी अधिक जटिल होगा और डेवलपर को दृढ़ता परत के बारे में बहुत कुछ समझ में आ जाएगा, तो उसे अब तक की जरूरत है (यह मानते हुए कि आपके पास एक टीम है और नहीं बस एक व्यक्ति)

— पॉल

मुझे लगता है कि यहाँ LINQ का उल्लेख करना कम से कम 1. से संबंधित है

— केसी कुबैल

Answer 1

ये मेरा विचार हे। जबकि मैं देख रहा हूं कि आप कहां से आ रहे हैं, मैं इसे सिर्फ डिजाइन के नजरिए से नहीं देख सकता।

डेटा की दृढ़ता अत्यंत जटिल विषय है। और इसलिए प्रोग्रामिंग लैंग्वेज हैं। दोनों के संयोजन से जटिलता विस्फोट होगा। यह वास्तव में लोगों को वास्तव में इसका उपयोग करने के लिए दोनों अच्छे बनाने के लिए बहुत प्रयास करेगा। मुझे लगता है कि पहले से ही उल्लेख किया गया MUMPS अच्छा उदाहरण है। या आप विभिन्न एसक्यूएल वेरिएंट को देख सकते हैं जिनकी पूरी भाषा उनके ऊपर है। वे उपयोग करने योग्य हो सकते हैं, लेकिन मुझे नहीं लगता कि लोग स्वेच्छा से उनका उपयोग करेंगे।

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

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

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

Comments

टीएल; डीआर "एक अच्छा विचार नहीं है क्योंकि उन्हें एकजुट करने से चिंताओं के पृथक्करण का उल्लंघन होता है"

— 22

Answer 2

ऐसा लगता है कि आप कुछ प्रमुख धारणाएँ बना रहे हैं। उदाहरण के लिए, आप मान रहे हैं कि हर कोई संबंधपरक डेटाबेस के लिए लिख रहा है। यह सिर्फ मामला नहीं है, अन्य फ्लेवर (ऑब्जेक्ट डीबी, दस्तावेज़ डीबीएस, आदि) के डेटाबेस के बहुत सारे उदाहरण हैं जो सभी कोड लिखने और दृढ़ता का प्रबंधन करने के लिए एक देशी प्रोग्रामिंग भाषा का उपयोग करते हैं।

उदाहरण के लिए, Db4O जावा और C # दोनों के साथ संगत है, जावा में ObjectDB, विभिन्न भाषाओं में वेलोसिटीबीडी। MongoDB के ड्राइवर सभी को अपनी मूल प्रोग्रामिंग भाषा में सामान लिखते हैं (बोनस यदि आप जावास्क्रिप्ट कर रहे हैं, तो इसका मतलब है कि शेल समान सिंटैक्स का भी उपयोग करता है), और इसी तरह।

विभिन्न स्थानों पर चर्चा का एक बहुत कुछ है, जिसके बारे में डीबी इंजन क्या संदर्भों में बेहतर हैं, और क्यों, इस उत्तर के दायरे के लिए बहुत अधिक, इस बहुत साइट पर एक बंद प्रश्न शामिल करने के लिए। अपशॉट यह है कि वे अलग-अलग चीजों के लिए अनुकूलित हैं, और हाल ही में जब तक कि SQL को व्यावसायिक अनुप्रयोगों के लिए 'सबसे कम आम भाजक' के रूप में माना जाता था क्योंकि आपको ACID और प्रदर्शन के मामले में मुफ्त में बहुत कुछ मिलता है (हालांकि उन दोनों को बदल रहे हैं हाल ही में आर्किटेक्चर और आवश्यकताएं बदल गई हैं)।

यह भी ध्यान देने योग्य है कि वास्तव में पहले "सभी में एक" प्रकार के बहुत सारे दृष्टिकोण थे। मेनफ्रेम भाषाओं में अक्सर अपने स्वयं के दृढ़ता तर्क का निर्माण होता था, और स्मॉलटाक जैसी भाषाएं होती हैं जो कोड और डेटा के बीच अंतर नहीं करती हैं। फिर, वे अक्सर कुछ उपयोग के मामलों के लिए अच्छे होते हैं लेकिन सभी नहीं।

Answer 3

1. हां (मुझे नहीं) इसे MUMPS कहा जाता था ।

2. इस के अनुसार इस पूर्व SE.SE प्रश्न , या इस लेख , गलसुआ बहुत अच्छी तरह से नहीं बनाया गया था। लेकिन वास्तव में स्वास्थ्य उद्योग में उपयोग किया गया था (और मुझे लगता है कि अभी भी मौजूदा सिस्टम इसका उपयोग कर रहे हैं), इसलिए कुल विफलता नहीं।

3. आपको इसके बारे में जानकारी निश्चित रूप से मिल जाएगी अब आप जानते हैं कि क्या खोजना है। उपरोक्त विकिपीडिया लिंक से शुरू करें।

4. ऑब्जेक्ट-ओरिएंटेड डेटाबेस के लिए खोजें, उनमें से कई भाषा-विशिष्ट हैं। उन्होंने ऑब्जेक्ट-रिलेशनल मिसमैच को ओआरएम की तुलना में सरल तरीकों से संबोधित करने की कोशिश की।

Comments

मम्प्स में डेटाबेस का उपयोग .... SK = 0 FSK = $ O (^ VA (200, K)) Q: 'KW $ P (^ VA (200, K, 0), U, 1),! एक प्रसिद्ध कण्ठमाला प्रणाली से रोगी के नाम प्रिंट करता है। समस्या सुलझ गयी? इतना नहीं।

— joshp

मेरा एक सहकर्मी है जो MUMPS द्वारा शपथ लेता है। इसके बाद के संस्करणों (कैश) में अधिक अनुमानित वाक्यविन्यास था।

— एलेक्सी

@Alexey: मुझे MUMPs के बारे में ज्यादा जानकारी नहीं है, लेकिन ऐसा लगता है कि सिंटैक्स की तुलना में बड़ी समस्याएं एरर-प्रिविंग स्कूपिंग नियम थे, जो एक बड़े कार्यक्रम को एक बुरा सपना बनाने और विकसित करने के लिए बनाए गए थे।

— डॉक ब्राउन

@DocBrown वहाँ आप वास्तव में है। स्कोपिंग नियम विधानसभा भाषा की तरह एक सा है। आमतौर पर जिस तरह से कण्ठमाला लिखी जाती है, उसके साथ बहुत सारी समस्याएं हैं, यह ओपी के सवाल से विचलित करता है।

— 3

Answer 4

वास्तव में कई प्रणालियां हैं जो डेटाबेस और प्रोग्रामिंग भाषा को एक ही वातावरण में एकीकृत करती हैं।

आप जो वर्णन करते हैं, शायद वह सबसे छोटा है। मेमोरी में ऑब्जेक्ट एक "छवि" में बना रहता है, इसलिए भाषा वातावरण बॉक्स से बाहर एक (ऑब्जेक्ट) डेटाबेस का उपयोग किया जा सकता है। और अधिकांश आधुनिक भाषा में कुछ प्रकार की अंतर्निहित दृढ़ता तंत्र है जिसका अर्थ है कि भाषा के वातावरण में वस्तुओं को भाषा का उपयोग करके ही बनाए रखा जा सकता है।

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

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

इन मामलों में यह वास्तव में बहुत सुंदर और सुविधाजनक है कि डेटाबेस को प्रोग्रामिंग भाषा के साथ एकीकृत किया जाए और "प्रतिबाधा बेमेल" से बचें। तो क्यों लोग अभी भी प्रोग्रामिंग माहौल से अलग डेटाबेस का उपयोग करते हैं और कुछ ORM- कीचड़ के साथ पुल करने की कोशिश करते हैं?

यह पता चलता है कि किसी भी विशिष्ट प्रोग्रामिंग भाषा और पर्यावरण से अलग डेटा और क्वेरी करने के कई फायदे हैं।

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

Answer 5

यह बहुत अच्छा सवाल है जो मैं अपने सिर में कई बार संसाधित कर रहा था। आपकी समस्या को हल करने वाले मौजूदा समाधान का एक उदाहरण एक ग्राफ डेटाबेस ArangoDB है जिसमें आप नियंत्रकों को लिखने के लिए जावास्क्रिप्ट (आंतरिक इंजन पर चलने) का उपयोग करते हैं जो पूरे वेब पेजों को उत्पन्न कर सकते हैं। JSON का उपयोग करके डेटा को स्टोरेज से / पास किया जाता है, इसलिए यह जावास्क्रिप्ट में मूल रूप से सुलभ है और क्वेरी एक एम्बेडेड क्वेरी भाषा में किया जाता है। इसलिए यह मामला डेटाबेस में चलाए जा रहे जावास्क्रिप्ट का एक उदाहरण है।

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

मेरी व्यक्तिगत राय में, यह एक अच्छा दृष्टिकोण है और अगर डेटाबेस एक तरह का नक्शा / कम करने की सुविधा का समर्थन करता है, जो एकत्रित डेटा / टेक्स्ट इंडेक्स और वास्तविक समय में अन्य अक्सर क्वेरी किए गए डेटा को अपडेट करेगा, तो बीच में एक पतली सुरक्षा परत जोड़ देगा (कॉल इसे लोड करें) बैलेंसर) वितरित डेटाबेस में चल रहा एक कार्यात्मक अनुप्रयोग बना देगा।

Answer 6

1. वास्तव में ऐसी एकीकृत प्रणाली का निर्माण किया

हाँ, मैंने किया था कि में Sciter ।

लेखक की स्क्रिप्ट एक " जावास्क्रिप्ट ++ " है जिसमें अंतर्निहित दृढ़ता है:

var ndb = Storage.open(pathname);
ndb.root = { ... root object ... };

ndb.rootजेएस के संदर्भ में सामान्य वस्तु कहां है। इसकी सभी संपत्तियां और उप-वस्तुएं सुलभ हैं, जो जरूरत पड़ने पर DB में संग्रहीत और संग्रहीत की जाती हैं - पारदर्शी रूप से कोड के लिए:

ndb.root.accounts[2].firstName = "John";
var name = ndb.root.accounts[3].firstName;

डेटा को DB में या तो जीसी चक्र पर संग्रहीत किया जाता है, जब पर्याप्त मेमोरी नहीं होती है, या स्पष्ट ndb.commit()कॉल पर।

Storageक्लास के साथ Indexक्लास होती है - यूनीक / नॉन-यूनीक कीज के साथ स्टैंटिबल ऑर्डर किए गए ऑब्जेक्ट कलेक्शन।

फ़ीचर सेट MongoDB या अन्य NoSQL डेटाबेस के समान है, लेकिन आईडी के लिए अलग से ORM की आवश्यकता नहीं है - db का उपयोग पूरी तरह से स्क्रिप्ट के माध्यम से किया जाता है।

Answer 7

मैं इसके लिए पूरी तरह से हूं और मुझे नहीं पता कि कहां से शुरू किया जाए। एसक्यूएल शानदार हो सकता है और मुझे लगता है कि यह सब शक्ति और आपके सभी उद्देश्य प्रोग्रामिंग भाषा में अधिकार की गारंटी देने के लिए बहुत अच्छा होगा (इसके बजाय प्रश्नों को स्ट्रिंग के संग्रह या उपयोग के रूप में लिखने के लिए, भगवान ना करे, एक ORM)।

आपके विचार के बारे में जानने वाला एकमात्र सिस्टम एक्वामेटा (टैग लाइन: "पोस्टरेक् सीक्यू में निर्मित वेब देव स्टैक" कहलाता है; देखें https://github.com/aquametalabs/aquameta , http://aquameta.org )। कुछ ऐसे इंट्रो वीडियो हैं जो अपने आप में विचार (youtube.com/watch?v=jz74upW7TN0, youtube.com/watch?v=cWGm9eYUYUk&t=29s, youtube.com/watch?v=xRoUQGUmiMg) से कम पागल नहीं हैं। और जब मैं पागल कहता हूं, तो मेरा मतलब है कि उन्होंने पोस्टग्रेज के अंदर अपने स्वयं के संपादक और अपने स्वयं के संस्करण नियंत्रण प्रणाली को लागू किया।

Answer 8

मुझे लगता है कि यह माइक्रोसॉफ्ट के LINQ के आविष्कार के लिए औचित्य था। यह कई वर्षों से पूर्ण पैमाने पर उत्पादन उपयोग में है, इसलिए इसके बारे में साहित्य खोजना आसान है और वास्तविक दुनिया के अनुभवों, सकारात्मक और नकारात्मक दोनों से प्रतिबिंब। (अधिकांश नेट विकास दुकानें इसे गले लगाती हैं।)

Linq पर एक अच्छा प्रारंभिक बिंदु: https://docs.microsoft.com/en-us/dotnet/csharp/linq/

Comments

देखें आपका उत्तर किसी अन्य महल में है: उत्तर एक उत्तर नहीं है?

— gnat

Linq-to-SQL एक ORM का एक घटक है, जो विशेष रूप से वह नहीं है जिसके बारे में ओपी पूछ रहा है।

— जैक्सबी

मैंने कहा नहीं linq-to-sql। मैं केवल linq के बारे में ही बात कर रहा था, जिसे प्रोग्रामिंग भाषा में बनाया गया है, अज्ञेय किस डेटा स्टोर के पीछे है, जो ओपी के बारे में पूछ रहा था।

— क्ले