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

Question

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

Answer 6

आप कागज बेन मोसली और पीटर मार्क्स द्वारा, यहाँ उपलब्ध "राल गड्ढे से बाहर" पर गौर करना चाहिए: "Out of the Tar Pit" (Feb. 6, 2006)

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

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

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

Answer 7

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

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

# 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 के पीछे यह मुख्य विचार है।

Answer 8

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

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

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

Answer 9

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

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

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

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