घटना / गतिविधि डेटा के लिए JSON ऑब्जेक्ट्स के लिए एक रिलेशनल डेटाबेस का उपयोग करना

Question

मैं एक ऐसी परियोजना पर काम कर रहा हूँ जहाँ मैं एक मानक SQL संबंधपरक डेटाबेस या JSON ऑब्जेक्ट का उपयोग करके किसी घटना या गतिविधि के बारे में डेटा स्टोर करने के बीच निर्णय लेने की कोशिश कर रहा हूं।

परियोजना कई ईवेंट प्रकारों पर डेटा संग्रहीत करेगी, इसलिए मैंने इस प्रश्न के लिए केवल एक ईवेंट प्रकार का वर्णन करने का निर्णय लिया है।

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

डेटा दोनों सरल ("मुझे 'x' नाम के साथ घटनाओं का पता लगाएं) और जटिल (" मेरे x से संगीत शैली और 'y' लागत वाले 'y' लागत वाले आयोजनों को मेरे वर्तमान से '' का उपयोग करके '' उपयोगकर्ताओं को समझा जाएगा। " स्थान ") प्रश्न। डेटा वेब प्रपत्र का उपयोग करके उपयोगकर्ताओं द्वारा प्रस्तुत किया जाएगा।

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

मैं अपनी आवश्यकताओं को देखते हुए प्रत्येक दृष्टिकोण के पेशेवरों और विपक्षों पर किसी भी विचार की सराहना करूंगा। यदि आपको कुछ भी स्पष्ट करने की आवश्यकता है, तो कृपया बेझिझक पूछें।

{
    "event": {
        "eventID":{
            "type":"string"
        },  
        "eventType":{
            "type":"array",
            "eventTypeItem":{
                "type":"string"
            }
        },
        "eventName":{
            "type":"string"
        },      
        "eventDescription":{
            "type":"string"
        },
        "eventVenueList":{
            "type":"array",
            "eventVenueListID":{
                "type":"integer"
            }
        },
        "eventURL":{
            "type":"string"
        },
        "eventTwitter":{
            "type":"string"
        },
        "eventFB":{
            "type":"string"
        },
        "eventInstagram":{
            "type":"string"
        },
        "eventEmail":{
            "type":"string",
            "format":"email"
        },
        "eventContactPerson":{
            "type":"string"
        },
        "eventDoorTime": {
            "type":"string",
            "format":"date-time"
        },  
        "eventPerformerIDList":{
            "type":"array",
            "liveMusicPerformerID":{
                "type":"integer"
            }
        },  
        "eventSetList":{
            "type":"array",
            "eventPerformerID":{
                "type":"integer"
            },
            "eventPerformerStartTime":{
                "type":"string",
                "format":"date-time"
            },
            "eventPerformerEndTime":{
                "type":"string",
                "format":"date-time"
            }                                   
        },
        "eventDateList": {
            "type":"array",
            "eventDateItem": {
                "type":"string",
                "format":"date-time"
            }   
        },
        "eventDateStartTime": {
            "type":"string",
            "format":"date-time"
        },
        "eventDateEndTime": {
            "type":"string",
            "format":"date-time"
        },
        "eventTicket":{ 
            "type":"array",
            "eventTicketType":{
                "type":"string" 
            },
            "eventTicketLowPrice":{
                "type":"number"
            },
            "eventTicketHighPrice":{
                "type":"number" 
            },
            "eventDatesAdvancePrice": {
                "type":"number"
            }   
        }
    },  
    "performer": {
        "performerID": {
            "type":"integer"
        },
        "performerType": {
            "type":"string"
        },
        "performerName": {
            "type":"string"
        },
        "performerAlternateName": {
            "type":"array",
            "performerAlterateNameItem":{
                "type":"string"
            }
        },
        "performerGenreList": {
            "type":"array",
            "performerGenreItem":{
                "type":"string"
            }
        },
        "performerURL": {
            "type":"string"
        }                                       
    }
}   

Comments

मुझे साइट की आवश्यकताओं का पता नहीं है, लेकिन मैं इसके द्वारा खोज करना चाहता हूं: कलाकार, स्थान और संभवतः दिनांक। क्या यह एक समस्या होगी क्योंकि वे सरणी प्रकारों में आयोजित किए जाते हैं?

— जेएफओ

क्या आप प्रासंगिक सरणी में मूल्यों की खोज के लिए अपनी क्वेरी को प्रोग्राम नहीं कर सकते हैं?

— zgall1

JSON स्टोरेज फॉर्मेट नहीं है। सच है, आप सामान की पाठ फ़ाइलों का उपयोग करके डेटा स्टोर कर सकते हैं, लेकिन केवल परिदृश्यों के सबसे सरल के तहत। JSON के संबंधपरक डेटाबेस की तुलना में "नया" होने के कारण आपके निर्णय की कोई प्रासंगिकता नहीं है।

— रॉबर्ट हार्वे

मुझे लगता है कि यह स्टोरेज फॉर्मेट नहीं है। मेरा मतलब था कि मैं JSON प्रारूपण के साथ डेटा को संग्रहीत करने के लिए MongoDB या Postgre की JSON ऑब्जेक्ट का उपयोग कर सकता हूं।

— zgall1

@RobertHarvey और मतदाताओं, में आजकल (2017) JSON है एक दुकान प्रारूप : देखने PostgreSQL 9.6+ ... बेसिक ~ 2012, पेशेवर के बाद से और के बाद से अंतिम 2015 (JSONb डेटाप्रकार) परिपक्व।

— पीटर क्रस

Answer 1

मुझे लगता है कि आपका प्रश्न वास्तव में उबलता है: मुझे आरडीबीएमएस बनाम नोएसक्यूएल दृष्टिकोण का उपयोग कब करना चाहिए? आप JSON जल्दी (एक NoSQL-ish निर्णय) पर बसे, शायद इसलिए कि आपको अजाक्स उपभोक्ताओं को मिला है।

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

बेशक, यहां तक ​​कि ये सामान्य दिशानिर्देश भी ठोस नहीं हैं। कारण गूगल गूगल फाइल सिस्टम, MapReduce (काम जो डौग काटना द्वारा इस्तेमाल किया गया था याहू पर Hadoop निर्माण करने के लिए) विकसित और बाद में BigQuery (बड़े पैमाने पर डेटा के प्रबंधन की एक NoSQL उन्मुख [स्कीमा-] जिस तरह से) ठीक था क्योंकि वे तदर्थ का एक बहुत था BI अनुरोध करता है, और वे टेरा / पेटा / एक्सा / ज़ेटा / योटा तराजू तक पैमाना करने के लिए संबंधपरक दृष्टिकोण प्राप्त नहीं कर सके। केवल व्यावहारिक दृष्टिकोण को स्केल करना था, जो कुछ एड-हॉक-क्वेरी उपयोगकर्ता मित्रता का त्याग करते हुए एक RDBMS प्रदान करता है, और एक सरल एल्गोरिथ्म (MapReduce) को प्रतिस्थापित करता है जिसे किसी भी क्वेरी के लिए आसानी से कोडित किया जा सकता है।

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

'परामर्श के लिए कल्पित बौनों के पास न जाएं, क्योंकि वे दोनों नहीं और हां कहेंगे।' - फ्रोडो

Comments

"हमारा पेशा इंजीनियरिंग उन्मुख माना जाता है, न कि फैशन उन्मुख, इसलिए हमारी वृत्ति को चुनना चाहिए ..." सबसे अच्छा समाधान जो काम करता है? ;)

— Bink

Answer 2

मेरा मानना ​​है कि यहाँ और भी विचार हैं जिनकी आपको तलाश नहीं है। यहां दो व्यापक चिंताएं हैं:

• भंडारण
• खोज और पुनर्प्राप्ति

भंडारण

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

खोज

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

हालाँकि यह बहुत अधिक अतिरिक्त काम लगता है, आप बाद में एक पूर्ण पाठ खोज इंजन का उपयोग करने की दूरदर्शिता के लिए खुद को धन्यवाद देंगे। NoSql डेटाबेस या RDBMS में से कोई भी SOLR / Lucene के प्रदर्शन और चपलता के करीब नहीं आता है।

Answer 3

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

उस ने कहा, मैं आपके प्रश्न को संकुचित कर सकता हूं: NoSQL और RDBMS के पेशेवरों और विपक्ष क्या हैं ? और यह पहले से ही 'नेट पर हजार बार उत्तर दिया जा चुका है।

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

इस तरह आप अंत में तय कर सकते हैं कि किस रास्ते पर जाना है, अन्यथा दी गई जानकारी के आधार पर निर्णय लेना वास्तव में कठिन होगा क्योंकि दोनों विकल्प काफी अच्छी तरह से फिट हो सकते हैं।

Answer 4

अधिकांश अनुप्रयोगों में आवश्यकताएं होती हैं

1. इनपुट डेटा, कुछ प्रोसेसिंग करते हैं, डेटा को बचाते हैं, डेटा को पुनः प्राप्त करते हैं और डेटा को क्वेरी करते हैं। डेटा पर रिपोर्ट जनरेट करने की आवश्यकता भी हो सकती है।
2. सिस्टम के विभिन्न हिस्सों के बीच या बाहरी सिस्टम के साथ डेटा का आदान-प्रदान

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

आइटम 2 के लिए आवश्यकताओं को प्राप्त करने के लिए XML, JSON आदि सहित सिस्टम के बीच डेटा इंटरचेंज की अनुमति देने के लिए कई अलग-अलग तरीके हैं।

ये विधियाँ किसी उपयोगकर्ता द्वारा डेटा संरचना को परिभाषित करने की अनुमति देती हैं और भाषा स्वतंत्र होती हैं जो डेटा का आदान-प्रदान करने के लिए प्रसार प्रणाली की अनुमति देती हैं।

अपने विशेष मामले में आप JSON का सही ढंग से उपयोग कर रहे हैं, संगीत कार्यक्रमों के एक सेट का वर्णन कर रहे हैं। जब आप JSON प्रारूप में डेटा संग्रहीत कर सकते हैं तो इस डेटा को खोज सकते हैं क्योंकि संगीत की बढ़ती घटनाओं की संख्या धीमी और अक्षम होगी।

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

JSON दृष्टिकोण के साथ एक अतिरिक्त समस्या एक बदलती डेटा संरचना है। वर्तमान में आपकी संरचना अपेक्षाकृत सरल है। आप कई महीनों तक इस संरचना का उपयोग कर सकते हैं और फिर एक अतिरिक्त फ़ील्ड की पहचान की जाती है। तब आप अपने सभी मौजूदा JSON ऑब्जेक्ट्स के साथ क्या करते हैं? इन्हें अद्यतन करना समस्याग्रस्त होगा।

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

संक्षेप में प्रौद्योगिकी के प्रत्येक टुकड़े को डेटा इंटरचेंज के लिए JSON और डेटा दृढ़ता के लिए डेटाबेस के लिए डिज़ाइन किया गया था।

Answer 5

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

केवल इसलिए कि कुछ डेटा विशुद्ध रूप से रिलेशनल हैं, इसका मतलब यह नहीं है, अब, इसे कुछ RDBMS (SQL) में बनाए रखा जाना चाहिए। IMO संबंधपरक डेटा ग्राफ डेटाबेस में बेहतर अनुवाद करेगा।

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

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

NoSQL को ध्यान में रखते हुए आप ग्राफ़ डेटाबेस में भी देख सकते हैं यदि आप बहुत ही जटिल प्रश्नों का उपयोग करने की योजना बनाते हैं, क्योंकि ये आपको आसानी से बनाने में लाभ देंगे, और उन्हें बहुत तेज़ी से निष्पादित भी करेंगे।

Answer 6

मुझे लगता है कि आपको दोनों का उपयोग करना चाहिए और मैं इसे 'बनाम' निर्णय के रूप में नहीं देखता हूं।

एक रिलेशनल डेटाबेस डेटा के तेज और कुशल भंडारण और पुनर्प्राप्ति के लिए समझ में आता है जिसमें संबंधपरक गुण होते हैं।

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

इसलिए मैं डेटा भंडारण प्रारूप के लिए डेटा भंडारण और JSON के लिए SQL की सिफारिश करूंगा।

यह सच है कि Mongo, Redis इत्यादि जैसे noSQL key-value विकल्प नहीं हैं, इनका लाभ संभवतः JSON प्रारूप में मैपिंग के लिए होगा, लेकिन आमतौर पर प्रश्नों के लिए उपयोग करना थोड़ा कठिन होता है। उनके साथ मुख्य बाधा सामान्य आईटी समुदाय द्वारा अपरिचितता है, खासकर जब SQL की तुलना में जो इतनी अच्छी तरह से जाना जाता है और लगभग हर स्थिति के लिए उपलब्ध संसाधनों और ज्ञान का एक विशाल सरणी कल्पनाशील है।

Comments

अगर मुझे प्रश्नों में नॉएसक्यू की-वैल्यू स्टोरेज पद्धति का उपयोग करने की एक अच्छी समझ के साथ एक प्रोग्रामर ढूंढना था, तो क्या आप कहेंगे कि डेटा स्टोरेज फॉर्मेट के रूप में JSON का उपयोग करने से दूर करने के लिए सबसे महत्वपूर्ण चुनौती होगी?

— zgall1

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

— जेएम बेकर