डेटाबेस और कार्यात्मक प्रोग्रामिंग बाधाओं पर हैं?


122

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

चीजों के OOP के बारे में मुझे एक और अधिक उत्पादक डेवलपर बना दिया गया था। वस्तु-संबंधपरक मैपर की खोज थी जैसे कि MyGeneration d00dads for .Net, Class :: DBI for perl, ActiveRecord for ruby, इत्यादि ने मुझे दूर रहने की अनुमति दी। पूरे दिन डालने और बयानों को लिखने से, और वस्तुओं के रूप में आसानी से डेटा के साथ काम करने पर ध्यान केंद्रित करने के लिए। बेशक, मैं अभी भी एसक्यूएल क्वेरी लिख सकता था जब उनकी शक्ति की आवश्यकता थी, लेकिन अन्यथा यह पर्दे के पीछे अच्छी तरह से अमूर्त था।

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

(ध्यान दें कि मैंने वेबलॉक या लिंक्स को बहुत करीब से नहीं देखा है, मैं बस गलतफहमी हो सकती है कि उनका उपयोग कैसे किया जाता है)।

तो सवाल यह है कि वेब एक्सेस के डेटाबेस एक्सेस के अंश (जो मुझे लगता है कि बहुत बड़े हैं) के लिए, या अन्य विकास के लिए एक sql डेटाबेस के साथ इंटरफेस की आवश्यकता होती है, जो हमें निम्नलिखित रास्तों में से एक के लिए मजबूर करने वाला प्रतीत होता है:

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

स्पष्ट रूप से, इनमें से कोई भी विकल्प आदर्श नहीं लगता है। इन मुद्दों को दरकिनार करने का एक तरीका मिल गया है? क्या वास्तव में यहाँ भी एक मुद्दा है?

नोट: मैं व्यक्तिगत रूप से FP के मोर्चे पर LISP से सबसे अधिक परिचित हूं, इसलिए यदि आप कोई उदाहरण देना चाहते हैं और कई FP भाषा जानते हैं, तो लिस्प संभवतः पसंद की भाषा होगी

पुनश्च: वेब विकास के अन्य पहलुओं के लिए विशिष्ट मुद्दों के लिए यह प्रश्न देखें ।


इसे भी देखें: stackoverflow.com/questions/218190/…
WW

4
क्लोजुरेक्लाइन और हास्केलबीडी की जाँच करें। वे एब्स्ट्रक्शन लेयर्स हैं जो रिलेशनल बीजगणित का उपयोग करते हैं।
मस्से

10
आप गलत आधार के साथ शुरुआत कर रहे हैं। कार्यात्मक प्रोग्रामिंग सभी स्पष्ट रूप से और पूरी तरह से प्रबंधन की स्थिति के बारे में है। वे वास्तव में डेटाबेस के साथ बहुत अच्छी तरह से काम करते हैं।
लूसियन

3
एसक्यूएल सबसे सफल कार्यात्मक-प्रोग्रामिंग केंद्रित भाषाओं में से एक है, मुझे नहीं लगता कि इसमें कोई अंतर्निहित कठिनाई है।
डगलस

3
आपके # 2 और # 3 एक झूठे द्वंद्ववाद हैं। कच्ची एसक्यूएल लिखना कुछ ऐसा नहीं है जिसे जरूरी रूप से टाला जाना चाहिए, और डेटाबेस पर सार जरूरी नहीं कि ओओपी-एस्क हो।
दान बर्टन

जवाबों:


45

सबसे पहले, मैं यह नहीं कहूंगा कि सीएलओएस (कॉमन लिस्प ऑब्जेक्ट सिस्टम) "छद्म-ऊ" है। यह प्रथम श्रेणी का OO है।

दूसरा, मेरा मानना ​​है कि आपको अपनी आवश्यकताओं के अनुरूप प्रतिमान का उपयोग करना चाहिए।

आप स्टेटलेस रूप से डेटा स्टोर नहीं कर सकते हैं, जबकि एक फ़ंक्शन डेटा का प्रवाह है और वास्तव में राज्य की आवश्यकता नहीं है।

यदि आपको कई ज़रूरतें हैं, तो अपने प्रतिमानों को मिलाएँ। केवल अपने टूलबॉक्स के निचले दाएं कोने का उपयोग करके अपने आप को प्रतिबंधित न करें।


3
बस मज़े के लिए, मुझे लगा कि मैं datalog का उल्लेख करूंगा जो एक अधिक स्टेटलेस डेटाबेस बनने का प्रयास करता है। यह सभी कार्यों को रिकॉर्ड करता है, जैसे "उपयोगकर्ता को पोस्ट 1233 पसंद है।" ये क्रियाएँ डेटाबेस की सही स्थिति के लिए हल करती हैं। कुंजी यह है कि क्वेरी केवल म्यूटेशन के बजाय तथ्य हैं ...
चेत

80

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

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

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

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


"एसक्यूएल किसी भी फ्रंट एंड लैंग्वेज की तुलना में पहले दो विचारों को प्रभावी ढंग से प्रबंधित करने के लिए लिखा गया है।" क्या सचमे? फिर भी, क्या यह है कि SQL बाधाएं अभी भी इस तरह की चीजें नहीं कर सकती हैं ?
रॉबिन ग्रीन

लेकिन एक ट्रिगर, यह जटिल बाधाओं को संभालने में सक्षम होने के लिए ट्रिगर के मुख्य उद्देश्यों में से एक है।
एचएलजीईएम

2
मैं आपके अंतिम पैराग्राफ को स्थानांतरित करूंगा ताकि यह अग्रणी पैराग्राफ हो। बहुत अच्छा बिंदु, जो कि दूसरों को भी आग्रह करता है, जो एक बहु-प्रतिमान दृष्टिकोण है (एक आकार-फिट-सभी नहीं)।
pestophagous

31

आपको बेन मोस्ले और पीटर मार्क्स द्वारा "आउट ऑफ द टार पिट" पेपर यहाँ उपलब्ध होना चाहिए: "आउट ऑफ़ द टार पिट" (6 फरवरी, 2006)

यह एक आधुनिक क्लासिक है जो एक प्रोग्रामिंग प्रतिमान / प्रणाली का विवरण देता है जिसे कार्यात्मक-संबंधपरक प्रोग्रामिंग कहा जाता है। जबकि डेटाबेस से सीधे संबंधित नहीं है, यह चर्चा करता है कि सिस्टम के कार्यात्मक कोर से बाहरी दुनिया (डेटाबेस, उदाहरण के लिए) के साथ बातचीत को अलग कैसे किया जाए।

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

यह पेपर डेटाबेस और फ़ंक्शनल प्रोग्रामिंग को एकीकृत करने के बारे में सटीक उत्तर नहीं देगा, लेकिन यह आपको समस्या को कम करने के लिए एक सिस्टम डिज़ाइन करने में मदद करेगा।


4
क्या बढ़िया कागज है। आपके द्वारा दिया गया लिंक टूटा हुआ है (अस्थायी रूप से?), लेकिन मैंने कागज को shaffner.us/cs/papers/tarpit.pdf
pestophagous

2
@queque मूल लिंक अभी भी मृत है। मैंने केविन के जवाब में नई लिंक डाली।
डेविड टोनहोफर

25
  1. कार्यात्मक भाषाओं में स्टेटलेस रहने का लक्ष्य नहीं है, उनके पास राज्य के प्रबंधन को स्पष्ट करने का लक्ष्य है। उदाहरण के लिए, हास्केल में, आप राज्य के मठ को "सामान्य" राज्य के दिल के रूप में मान सकते हैं और आईओ मोनाद को राज्य का प्रतिनिधित्व करते हैं जो कार्यक्रम के बाहर मौजूद होना चाहिए। ये दोनों सन्यासी आपको (ए) स्पष्ट रूप से स्टेटफुल एक्ट्स का प्रतिनिधित्व करते हैं और (बी) रेफेरेंशियल ट्रांसपेरेंट टूल्स का इस्तेमाल करके कंपोज करके स्टेटफुल एक्शन का निर्माण करते हैं।

  2. आप कई ओआरएम का संदर्भ देते हैं, जो उनके नाम के अनुसार, सार डेटाबेस ऑब्जेक्ट्स के सेट के रूप में। ट्रूली, यह वह नहीं है जो एक रिलेशनल डेटाबेस में सूचना का प्रतिनिधित्व करता है! अपने नाम के अनुसार, यह संबंधपरक डेटा का प्रतिनिधित्व करता है। संबंधपरक डेटा सेट पर रिश्तों को संभालने के लिए SQL एक बीजगणित (भाषा) है और वास्तव में यह काफी "कार्यात्मक" है। मैं इस पर विचार करने के लिए इसे लाता हूं (क) ORMs डेटाबेस की जानकारी को मैप करने का एकमात्र तरीका नहीं है, (b) कि SQL वास्तव में कुछ डेटाबेस डिजाइनों के लिए एक बहुत अच्छी भाषा है, और (c) कि कार्यात्मक भाषाओं में अक्सर संबंधपरक बीजगणित होती है। मैपिंग जो एक मुहावरेदार में SQL की शक्ति को उजागर करता है (और हास्केल के मामले में, टाइपकास्ट किया गया) फैशन।

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


15

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

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

मुझे लगता है कि लिस्प में 'छद्म-ऊ' विचारों में उनकी योग्यता भी है। आप उन्हें आज़माना चाह सकते हैं। यदि वे आपके डेटा के साथ काम करने के तरीके को फिट नहीं करते हैं, तो आप वेबलॉक के ऊपर एक परत बनाने की कोशिश कर सकते हैं जो आपको अपने डेटा के साथ काम करने की अनुमति देता है। यह सब कुछ लिखने से आसान हो सकता है।

अस्वीकरण: मैं एक लिस्प विशेषज्ञ नहीं हूं। मुझे ज्यादातर प्रोग्रामिंग भाषाओं में दिलचस्पी है और लिस्प / सीएलओएस, स्कीम, एरलैंग, पायथन और रूबी के एक बिट के साथ खेल रहा हूं। दैनिक प्रोग्रामिंग जीवन में मैं अभी भी C # का उपयोग करने के लिए मजबूर हूं।


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

@ अमादिरो "निश्चित रूप से राज्य है"। बिलकुल यह करता है। हमारे पास हमेशा राज्य है। समस्या राज्य नहीं है, यह परिवर्तनशील स्थिति है । "कार्यात्मक प्रोग्रामिंग" का एक अच्छा हिस्सा राज्य अभ्यावेदन से छुटकारा पाने के बारे में है जो भंगुर हैं (उदाहरण के लिए वस्तु उदाहरण जो अन्य प्रक्रियाओं द्वारा बदल दिए जाते हैं, जबकि हम उनके लिए एक संदर्भ रखते हैं, गैर-लेन-देन में चोट के अपमान को जोड़ने के लिए)। Erlang में गैर-परिवर्तनशील स्थिति है और इसलिए कार्यात्मक प्रोग्रामिंग के इस मापदंड को हिट करता है। और इस प्रकार: जो भी प्रकार का डेटाबेस कभी भी समस्या नहीं है। डेटाबेस अपडेट एक समस्या है ( प्रोलॉग में बुरा दावा भी देखें )।
डेविड टोनहोफर

15

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

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

# Start: Time T
likes(db, "Bob")
=> "Suzie"
# Change who bob likes
...
likes(db "Bob")
=> "Alice"
# Recover the database from T
db = getDb(T)
likes(db, "Bob")
=> "Suzie"

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

उदाहरण के लिए, डेटामिक के पीछे यह प्रमुख विचार है ।


अच्छा लगा। मुझे डाटामिक के बारे में भी नहीं पता था। यह भी देखें: Datomic के लिए तर्क
डेविड टोनहोफर

12

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

Mnesia में लिखा है Erlang और वहाँ कम से कम एक वेब रूपरेखा (है Erlyweb ) है कि मंच के लिए उपलब्ध। एरलैंग स्वाभाविक रूप से एक साझा-कुछ थ्रेडिंग मॉडल के साथ समानांतर है, इसलिए कुछ निश्चित तरीकों से यह खुद को स्केलेबल आर्किटेक्चर के लिए उधार देता है।


1
मुझे नहीं लगता कि यह एक समाधान है। ऑब्जेक्ट-ओरिएंटेड डेटाबेस भी हैं, लेकिन आमतौर पर, आप एक पुराने पुराने रिलेशनल SQL डेटाबेस से कनेक्ट करना चाहते हैं।
jalf

4
आपके पास अभी भी OO भाषाओं और डेटाबेस के साथ एक प्रतिबाधा बेमेल है उसी तरह जैसे कि आपके पास कार्यात्मक-SQL प्रतिबाधा बेमेल है।
कंसर्नडऑफटुनब्रिजवल्स 13

1
@ConcernedOfTunbridgeWells मैं मनमाने ढंग से कहूंगा कि यह प्रतिबाधा बेमेल हैमर के साथ उन लोगों की कल्पना का एक अनुमान है, जिन्हें नाखून होने के लिए सब कुछ चाहिए। SQL के बारे में बहुत पतली परतें और ज्ञान सुरुचिपूर्ण ढंग से एक लंबा रास्ता तय कर सकते हैं, इसलिए jOOQ और इसी तरह के शिम।
डेविड टोनहोफर

6

डेटाबेस एक स्टेटलेस एपीआई में राज्य का ट्रैक रखने का सही तरीका है। यदि आप REST की सदस्यता लेते हैं, तो आपका लक्ष्य स्टेटलेस कोड लिखना है जो डेटास्टोर (या कुछ अन्य बैकएंड) के साथ इंटरैक्ट करता है जो पारदर्शी तरीके से राज्य की जानकारी का ट्रैक रखता है ताकि आपके क्लाइंट को न करना पड़े।

ऑब्जेक्ट-रिलेशनल मैपर का विचार, जहाँ आप डेटाबेस रिकॉर्ड को ऑब्जेक्ट के रूप में आयात करते हैं और फिर उसे संशोधित करते हैं, यह कार्यात्मक प्रोग्रामिंग के लिए उतना ही लागू और उपयोगी है जितना कि ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के लिए है। एक चेतावनी यह है कि कार्यात्मक प्रोग्रामिंग ऑब्जेक्ट को जगह में संशोधित नहीं करता है, लेकिन डेटाबेस एपीआई आपको जगह में रिकॉर्ड को संशोधित करने की अनुमति दे सकता है। आपके ग्राहक का नियंत्रण प्रवाह कुछ इस तरह दिखाई देगा:

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

डेटाबेस आपके परिवर्तनों के साथ रिकॉर्ड को अपडेट करेगा। शुद्ध कार्यात्मक प्रोग्रामिंग आपके प्रोग्राम के दायरे में पुन: असाइन किए गए चरों को अस्वीकार कर सकती है , लेकिन आपका डेटाबेस API अभी भी इन-प्लेस अपडेट की अनुमति दे सकता है।


5

मैं हास्केल के साथ सबसे सहज हूं। सबसे प्रमुख हास्केल वेब फ्रेमवर्क (रेल और Django के बराबर) को यसोड कहा जाता है। यह एक बहुत अच्छा है, प्रकार सुरक्षित, बहु-बैकेंड ORM लगता है। उनकी पुस्तक में दृढ़ता अध्याय पर एक नजर है ।


0

डेटाबेस और फंक्शनल प्रोग्रामिंग को फ्यूज किया जा सकता है।

उदाहरण के लिए:

क्लोजर रिलेशनल डेटाबेस सिद्धांत पर आधारित एक कार्यात्मक प्रोग्रामिंग भाषा है।

               Clojure -> DBMS, Super Foxpro
                   STM -> TransactionMVCC
Persistent Collections -> db, table, col
              hash-map -> indexed data
                 Watch -> trigger, log
                  Spec -> constraint
              Core API -> SQL, Built-in function
              function -> Stored Procedure
             Meta Data -> System Table

नोट: नवीनतम spec2 में, कल्पना RMDB की तरह अधिक है। देखें: कल्पना-अल्फ़ा २ विकी: स्कीमा-एंड-सलेक्ट

मैं वकालत करता हूं: NoSQL और RMDB लाभों के संयोजन को प्राप्त करने के लिए हैश-मैप के शीर्ष पर एक संबंधपरक डेटा मॉडल का निर्माण। यह वास्तव में posgtresql का एक रिवर्स कार्यान्वयन है।

बत्तख टाइपिंग: यदि यह एक बतख की तरह दिखता है और बतख की तरह होता है, तो उसे बतख होना चाहिए।

यदि clojure का डेटा मॉडल RMDB की तरह है, तो clojure की सुविधाएं जैसे RMDB और clojure का डेटा जोड़-तोड़ जैसे RMDB, clojure का RMDB होना चाहिए।

क्लोजर रिलेशनल डेटाबेस सिद्धांत पर आधारित एक कार्यात्मक प्रोग्रामिंग भाषा है

सब कुछ RMDB है

हैश-मैप (NoSQL) के आधार पर संबंधपरक डेटा मॉडल और प्रोग्रामिंग को लागू करें

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.