प्रोफेसर ने हमें बताया कि अनुक्रमित जावा वस्तुओं को संबंधपरक तालिकाओं को परिभाषित करने के बजाय बूँद के रूप में संग्रहीत करना है


21

वास्तव में सही विशेषताओं के साथ तालिकाओं को परिभाषित करने के बजाय, मेरे प्रोफेसर ने हमें बताया कि हम इस तरह से आईडी में वस्तुओं को मैप कर सकते हैं:

id (int)  |   Serialized Object (blob)
   1               10010110110

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

या तो मैं हमेशा के लिए उस मॉडल के साथ फंस गया हूं या मुझे अपने मॉडल को बदलने के लिए कुछ अन्य वास्तव में बदसूरत सामान करना होगा। ** यह पूरी चीजें मुझे बुरी तरह से लगती हैं। क्या मैं अपने प्रोफेसर से असहमत हूं? क्या ऐसा करने का कोई लाभ है जो मैंने नहीं सोचा है? अगर मैं सही हूं तो मुझे अपने प्रोफेसर से इस बारे में कुछ कहना चाहिए? वह मेरी पूरी कक्षा को यह बता रहा था और उसने यह भी कहा कि उसने इस तरह से परियोजनाएँ बनाई हैं। एक दूसरी राय बहुत अच्छी होगी।

कोर्स का नाम सॉफ्टवेयर डिजाइन है

मेरे प्रोफेसर ने यह नहीं कहा कि यह सबसे अच्छा तरीका था, लेकिन उन्होंने कहा कि यह संबंधपरक तालिकाओं को परिभाषित करने का एक वैध विकल्प था।

मॉडल किसी भी तरह से गतिशील नहीं है।


टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।
पॉल व्हाइट GoFundMonica कहते

जवाबों:


34
  1. यह, अपने आप में, एक बुरी चीज नहीं है - बिल्कुल नहीं। उचित संदर्भ (= सटीक आवश्यकताओं) के बिना "जो बेहतर है" के बारे में तर्क व्यर्थता में एक अभ्यास है।

  2. बोल्ड में हिस्सा गलत है। आप आसानी से नए क्षेत्रों को जोड़ने और पुरानी वस्तुओं के साथ पूर्ण द्विआधारी संगतता प्राप्त करने के लिए पहले से ही अनुक्रमित वस्तुओं का विस्तार कर सकते हैं। आप मूल को बदलने के बजाय बस नई कक्षाएं बना सकते हैं।

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

- अन्य उत्तरों को पढ़ने के बाद एक संपादन।

अन्य उत्तरों में से एक यह बताता है कि "इस मामले की कल्पना करना कठिन है, जहां विपक्ष से आगे निकल जाना है"।

क्योंकि पूरी चर्चा ठोस समस्याओं के बारे में होनी चाहिए (अन्यथा हम "बेहतर" और "बदतर") को भी परिभाषित नहीं कर सकते हैं, मैं आपको एक ठोस उदाहरण देता हूं। यह पूरी तरह से बना हुआ है, लेकिन मैंने जितना संभव हो उतने विवरणों को मांस देने की कोशिश की।

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

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

अब आपके पास दो बुनियादी विकल्प हैं:

  • चूंकि गेम जावा में लिखे गए हैं, आप आसानी से मॉडल ले सकते हैं, इसे सर्वर पर भेज सकते हैं, इसे कोड की एक पंक्ति में क्रमबद्ध कर सकते हैं और एक ब्लॉब के रूप में स्टोर कर सकते हैं। टेबल को "save_games" कहा जाएगा और इसमें खिलाड़ी के लिए विदेशी चाबियां होंगी और इसी तरह। डेटाबेस के दृष्टिकोण से एक "सेव गेम" एक अपारदर्शी, अविभाज्य बूँद है।

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

जस्टिन केव का जवाब कहता है, कि आपको दूसरे विकल्प के साथ जाना चाहिए। मुझे लगता है कि यह बहुत बड़ी गलती होगी।

इसके अलावा, मेरे पास एक कूबड़ है कि जस्टिन केव की धारणा यह है कि जो मैंने ऊपर प्रस्तुत किया है वह एक "बढ़त" या "दुर्लभ" मामला है। मेरा मानना ​​है कि जब तक वह किसी प्रकार के कठिन डेटा को प्रस्तुत नहीं कर सकता (दुनिया की सभी आईटी परियोजनाओं के प्रतिनिधि नमूने पर आधारित है, न कि केवल, कहो, अमेरिका में उद्यम अनुप्रयोगों), मैं इस तरह के विचार को एक प्रक्षेपण का एक क्लासिक मामला मानूंगा पूर्वाग्रह।

दरअसल, एक रिलेशनल डेटाबेस में सीरियलाइज्ड जावा ऑब्जेक्ट्स की समस्या इससे कहीं अधिक गहरी है जितना लगता है। यह 1NF के मूल को छूता है, अर्थात् एक विशेषता का डोमेन क्या है? । यदि आप वास्तव में इस विषय में रुचि रखते हैं, तो CJ Date द्वारा डेटाबेस पर उनकी तिथि: 2000-2006 के लेख में एक शानदार लेख है ।


टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।
पॉल व्हाइट GoFundMonica कहते

22

कैन और डू) लोग ऐसे प्रोजेक्ट्स को सफलतापूर्वक वितरित करते हैं जो इस प्रकार का काम करते हैं? दुर्भाग्य से, हाँ, वे ऐसा यथोचित करते हैं।

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

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

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

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


2
आपने क्या कहा, इसके अलावा मेरे दो सेंट। पुन: प्रयोज्यता प्रतिरूपकता और साझाकरण के बारे में है। ऑब्जेक्ट मॉडल ऑब्जेक्ट साझा करने और कोड का पुन: उपयोग करने पर ध्यान केंद्रित करता है। डेटाबेस मॉडल डेटा साझा करने और पुन: उपयोग करने पर ध्यान केंद्रित करता है। न तो मॉडल पूरी तरह से नैतिक है। न तो मॉडल पूर्णता है। और दोनों में सामंजस्य बिठाना बहुत मुश्किल है।
वाल्टर मिती

1
मैं इस बात से सहमत हूं, लेकिन मैं एक प्रोफेसर को कुछ सिखाने के लिए नफरत करता हूं और कहता हूं कि इसके बारे में सामना किए बिना बेहतर तरीका है। अन्य सभी गरीब छात्रों के बारे में क्या यह वर्ग है जो वास्तविक दुनिया में जाएगा यह सोचकर कि यह सही तरीका है?
केविन

ज़रूर। डेटा बनाने का नाटक करने वाली वस्तुओं पर यह सूत्रीकरण मात्रा होती है। और वे डेटा हैं, लेकिन बहुत उपयोगी डेटा नहीं हैं।
वाल्टर मिती

जैसे ही आप अपने ऐप का v2 जारी करना चाहते हैं, फायदा लगभग हमेशा मिटा दिया जाता है।
एंडी

10

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

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

क्या ऐसा करने का कोई लाभ है जो मैंने नहीं सोचा है?

स्टोरेज किए गए ऑब्जेक्ट का मतलब है कि आप स्कीमालेस डेटा स्टोर कर सकते हैं (ध्यान दें कि नाम के बावजूद, स्कीमालेस का आमतौर पर मतलब नहीं है कि वास्तव में कोई स्कीमा नहीं है, बल्कि केवल अंतर्निहित स्कीमा है)। ऐसे कई समस्याएँ हैं जहाँ आप संभवतः विकास के समय स्कीमा को समय से पहले परिभाषित नहीं कर सकते हैं, और जहाँ पारंपरिक संबंधपरक डेटाबेस डिज़ाइन का अनुसरण करने का अर्थ यह होगा कि आपको हर दूसरे सप्ताह डेटाबेस के स्कीमा को बदलना होगा, या यह कि आप एक तालिका के साथ समाप्त होंगे स्तंभों का 80% जो अप्रयुक्त हैं 80% समय, या सैकड़ों विभिन्न तालिकाओं को संग्रहीत करने के लिए जो वास्तव में एक ही डेटा है, जिनमें से कोई भी एक अच्छे डिज़ाइन को इंगित नहीं करता है। इस समस्या की जड़ आमतौर पर है क्योंकि आप एक गैर-संबंधपरक समस्या डोमेन को एक संबंधपरक डेटाबेस में ढाले जाने के लिए मजबूर करते हैं।

बेशक, बहुत सारी परियोजनाएँ हैं जहाँ लोगों को लगता है कि उन्हें ईएवी, योजनाबद्धता या बूँद की दुकान का उपयोग करने की आवश्यकता है जो अनावश्यक रूप से कारण बनते हैं जो एक परिहार्य दर्द होता है। आपको अपने प्रोफेसर से निश्चित रूप से चर्चा करनी चाहिए कि उसका तर्क क्या है और अपने तर्क प्रदान करें; तर्कों को सुनें, और तैयार रहें कि आप उससे सहमत हो सकते हैं, या नहीं, शायद वह गलत है।


7

मैंने पहले भी ऐसा किया है - कुछ विशेष परिदृश्यों में इसकी उपयोगी तकनीक हालांकि उपयोग किए गए क्रमांकन प्रारूप पर निर्भर करती है। यदि मैं ऐसा करता हूं, तो मुझे यकीन है कि मैं एक क्रमांकन प्रारूप का उपयोग करता हूं जो मुझे अपने मॉडल के पुराने संस्करणों (जैसे XML) को डी-सीरियल करने की अनुमति देता है।

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

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

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


6

जस्टिन केव सही है कि यह निरर्थक डेटा को जन्म दे सकता है, लेकिन यह वास्तव में इस बात पर निर्भर करता है कि आप अपने डेटाबेस को कैसे डिज़ाइन करते हैं।

किसी संपूर्ण वस्तु को एक बूँद में अनुक्रमित करने का दृष्टिकोण उतना अपमानजनक नहीं है जितना कि यहाँ के अधिकांश लोग सोचते हैं कि यह है। वास्तव में, कुछ अनुप्रयोगों के लिए, यह सबसे अच्छा डिज़ाइन हो सकता है जिसे आप कर सकते हैं, जैसा कि मैंने यहां बताया: /programming//a/12644223/1121352

दरअसल, किसी वस्तु को क्रमबद्ध करने से कम से कम दो लाभ होते हैं:

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

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

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

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

एक साइड नोट के रूप में, कुछ DB निर्माताओं द्वारा रिलेशनल और ऑब्जेक्ट मॉडल को एक साथ मिलाने के कुछ प्रयास हैं, जैसे PostSQL और PostgreSQL में JSON डेटाटाइप ताकि आप सीधे JSON को किसी भी रिलेशनल कॉलम की तरह प्रोसेस कर सकें, और SQL3 और OQL (ऑब्जेक्ट) क्वेरी (भाषा) SQL में (सीमित) ऑब्जेक्ट जोड़ने के लिए समर्थन करती है।

अंत में, यह संबंधपरक मॉडल और ऑब्जेक्ट मॉडल के बीच डिजाइन और समझौता का मामला है।

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


5

आइए एक व्यावहारिक उदाहरण दें कि मैंने अतीत में कब क्या किया है।

हमारे पास एक डेटाबेस है जिसमें एक मूली-उपयोगकर्ता एप्लिकेशन के लिए सभी डेटा शामिल हैं; डेटाबेस में उनके एक्सेस अधिकारों के साथ उपयोगकर्ताओं की एक तालिका भी है। यह सभी डेटा सामान्य रूप से अपेक्षित है।

फिर हमारे पास अनुरोध है कि एप्लिकेशन को याद है कि उपयोगकर्ता के पास कौन सी खिड़कियां खुली थीं और वे क्या कर रहे थे, ताकि यह अगली सुबह उपयोगकर्ता द्वारा काम शुरू करने पर राज्य को पुनर्स्थापित कर सके।

  • सबसे पहले अगर यह कभी-कभी विफल हो जाता है, तो क्या यह असंगत नहीं है

    • उदाहरण के लिए, यदि पहली बार कोई व्यक्ति एप्लिकेशन के नए संस्करण का उपयोग करता है, तो यह उन खिड़कियों को भूल जाता है, जिन्हें उन्होंने खोला था, इसलिए ...
  • इसलिए अगर वस्तुओं में बदलाव होता है तो 100% कमबैक होता है, और इसलिए हम ब्लॉक को नहीं पढ़ सकते हैं।

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

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

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


4

एक बहुत ही महत्वपूर्ण कारक: जावा सीरियलाइज़ेशन (एक किया गया है जो लागू करने में सक्षम है Serializable) अपने आप में एक बहुत ही खराब प्रारूप है, इसलिए आपको इसे स्थायी ऑब्जेक्ट स्टोरेज के लिए उपयोग नहीं करना चाहिए।

जावा क्रमांकन की कमियां शामिल हैं:

  • डेटा वास्तव में अन्य भाषाओं से पठनीय नहीं है।
  • सीरियलाइज्ड ऑब्जेक्ट्स की फॉरवर्ड कॉम्पैटिबिलिटी को बनाए रखना बहुत आसान नहीं है, वह यह है: यदि आप क्लास में फ़ील्ड्स जोड़ते हैं (या हटाते हैं) तो क्लास के पुराने वर्जन द्वारा बनाए गए ऑब्जेक्ट्स को पढ़ना इतना आसान नहीं है।
  • यह इतना तेज़ नहीं है (लेकिन आपका माइलेज अलग हो सकता है)

इसलिए यदि आप किसी अन्य क्रमांकन प्रारूप का उपयोग करते हैं, तो आपको एक अच्छा की-वैल्यू स्टोर मिलता है, यदि आप जावा क्रमांकन का उपयोग करते हैं तो आपको गड़बड़ होती है।


उत्तर में तथ्य केवल झूठे हैं: 1) प्रारूप एक विशिष्ट विनिर्देश द्वारा कवर किया गया है; 2) खेतों को जोड़ना कोई समस्या नहीं है, प्रारूप बहुत लचीला है; 3) गति वास्तविक डेटा पर निर्भर करती है, लेकिन JSON या XML जैसे प्रारूपों के लिए तुलनीय (कभी-कभी तेज, कभी-कभी धीमी) होती है। मूल रूप से, एक पंक्ति को छोड़कर पूरा उत्तर गलत है, "डेटा अन्य भाषाओं से वास्तव में पठनीय नहीं है"।
fdreger

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

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

1
फ़ील्ड जोड़ने के लिए आपको किसी भी तरीके को लिखने की आवश्यकता नहीं है, लेकिन यदि आप प्रभावित करना चाहते हैं कि कैसे वे deserialized हैं तो आपको उस व्यवहार को निर्दिष्ट करने की आवश्यकता है। मैं ऑब्जेक्ट स्कीमा को विकसित करने के deserialisation के साथ समस्याओं के लिए कुछ संदर्भ खोदने की कोशिश करूँगा।
जेबी

3

यह एक दिलचस्प धागा है जिसमें कुछ अच्छी तरह से सोचा जवाब दिए गए हैं। क्रमबद्ध वस्तुओं के भंडारण और पुनः प्राप्त करने के सभी निहितार्थों के साथ बातचीत नहीं करना, मुझे लगता है कि यह जवाब देना दिलचस्प होगा जो मैं डीबीए टीम या विकास टीम को दे सकता हूं:

कुंजी वर्तमान और भविष्य की आवश्यकताओं को पूरा करना है, और समाधान को यथासंभव सरल रखना है ताकि भविष्य के समर्थन कार्य को कम से कम किया जा सके। कार्यात्मक आवश्यकताएं और गैर-कार्यात्मक आवश्यकताएं (जैसे बुनियादी ढांचे और डेटाबेस) दोनों को पूरा किया जाना चाहिए। 80/20 नियम याद रखें। व्यवसाय के लिए ऐप के महत्व को समझें और विकास का कौन सा प्रयास उचित है।

अगर वे मुद्दे नहीं हैं, तो डेटाबेस स्पेस, स्पीड और मेमोरी पर लटका न रखें।

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

यदि समाधान एक प्रोटोटाइप या प्रारंभिक चरण / संस्करण होना है, तो चीजों को सरल रखने पर और भी अधिक तनाव है। जब तक आप इसके लिए योजना बनाते हैं, आप डेटा स्कीमा को बाद में बढ़ा सकते हैं।

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

इस बात पर विचार करते हुए कि सभी रिलेशनल डेटाबेस शुद्ध रिलेशनल डेटाबेस स्कीमा (जैसे स्टार, स्पेसियल, नॉन-रिलेशनल ..) का उपयोग नहीं करते हैं, ऐप भी रिलेशनल डेटाबेस को गैर-रिलेशनल स्टोर के रूप में उपयोग कर सकते हैं, जैसा कि प्रश्न में है। कई कोर बिजनेस डेटाबेस इस तरह से काम करते हैं।

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