डेटाबेस में JSON स्टोर करना बनाम प्रत्येक कुंजी के लिए एक नया कॉलम होना

213

मैं अपनी तालिका में उपयोगकर्ता से संबंधित डेटा संग्रहीत करने के लिए निम्नलिखित मॉडल लागू कर रहा हूं - मेरे पास 2 कॉलम हैं - uid(प्राथमिक कुंजी) और एक metaस्तंभ जो उपयोगकर्ता के बारे में अन्य डेटा को JSON प्रारूप में संग्रहीत करता है।

 uid   | meta
--------------------------------------------------
 1     | {name:['foo'], 
       |  emailid:['foo@bar.com','bar@foo.com']}
--------------------------------------------------
 2     | {name:['sann'], 
       |  emailid:['sann@bar.com','sann@foo.com']}
--------------------------------------------------

यह एक बेहतर तरीका है (प्रदर्शन के लिहाज से, डिजाइन के लिहाज से) एक-स्तंभ-प्रति-संपत्ति मॉडल है, जहां मेज की तरह कई कॉलम होगा की तुलना में uid, name, emailid।

मुझे पहले मॉडल के बारे में क्या पसंद है, आप अधिक से अधिक फ़ील्ड जोड़ सकते हैं, कोई सीमा नहीं है।

इसके अलावा, मैं सोच रहा था, कि अब मैंने पहला मॉडल लागू कर दिया है। मैं इस पर एक क्वेरी कैसे कर सकता हूं, जैसे, मैं उन सभी उपयोगकर्ताओं को लाना चाहता हूं जिनके पास 'फू' जैसा नाम है?

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

अपडेट करें

चूंकि बहुत अधिक कॉलम नहीं होंगे, जिस पर मुझे खोज करने की आवश्यकता है, क्या दोनों मॉडलों का उपयोग करना बुद्धिमान है? डेटा के लिए कुंजी-प्रति-स्तंभ जिसे मुझे खोजना है और दूसरों के लिए JSON (उसी MySQL डेटाबेस में)?

— ShuklaSannidhya
स्रोत

40

बड़ा सवाल! लेकिन आपने जवाब क्यों नहीं दिया? जो अन्य उपयोगकर्ताओं (मेरी तरह) की मदद करेगा

— सहर च।

198

अपडेट किया गया 4 जून 2017

यह देखते हुए कि इस प्रश्न / उत्तर ने कुछ लोकप्रियता हासिल की है, मुझे लगा कि यह अपडेट के लायक है।

जब यह प्रश्न मूल रूप से पोस्ट किया गया था, MySQL के पास JSON डेटा प्रकारों के लिए कोई समर्थन नहीं था और PostgreSQL में समर्थन अपनी प्रारंभिक अवस्था में था। 5.7 के बाद से, MySQL अब एक JSON डेटा प्रकार (एक बाइनरी स्टोरेज फॉर्मेट में) का समर्थन करता है , और PostgreSQL JSONB काफी परिपक्व हो गया है। दोनों उत्पाद निष्पादन JSON प्रकार प्रदान करते हैं जो JSON ऑब्जेक्ट की विशिष्ट कुंजियों को अनुक्रमित करने के लिए समर्थन सहित, मनमाने दस्तावेज़ों को संग्रहीत कर सकते हैं।

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

उस ने कहा, कुछ अनुप्रयोग पूरी तरह से संबंधपरक या दस्तावेज़-उन्मुख हैं। अधिकांश अनुप्रयोगों में दोनों का कुछ मिश्रण होता है। यहाँ कुछ उदाहरण हैं जहाँ मैंने व्यक्तिगत रूप से JSON को रिलेशनल डेटाबेस में उपयोगी पाया है:

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

मुझे यकीन है कि कुछ और भी हैं, लेकिन ये कुछ त्वरित उदाहरण हैं।

मूल उत्तर

यदि आप वास्तव में बिना किसी सीमा (एक मनमाना दस्तावेज़ आकार सीमा के अलावा) के साथ जितने फ़ील्ड चाहते हैं, उतना जोड़ने में सक्षम होना चाहते हैं, तो MongoDB जैसे NoSQL समाधान पर विचार करें।

संबंधपरक डेटाबेस के लिए: प्रति मान एक कॉलम का उपयोग करें। एक कॉलम में एक JSON बूँद को डालना प्रश्न के लिए लगभग असंभव बना देता है (और जब आप वास्तव में काम करते हैं तो आपको एक क्वेरी मिलती है) जब यह धीमा होता है।

अनुक्रमिक करते समय संबंधपरक डेटाबेस डेटा प्रकारों का लाभ उठाते हैं, और सामान्यीकृत संरचना के साथ कार्यान्वित होने का इरादा रखते हैं ।

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

— कॉलिन एम
स्रोत

1

चूंकि बहुत अधिक कॉलम नहीं होंगे, जिस पर मुझे खोज करने की आवश्यकता है, क्या दोनों मॉडलों का उपयोग करना बुद्धिमान है? डेटा के लिए कुंजी-प्रति-स्तंभ जिसे मुझे खोजना है और दूसरों के लिए JSON (उसी MySQL डेटाबेस में)?

— शुक्लसन्निध्य

3

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

— कॉलिन एम

5

" virtually impossible to query" - आज psql आपको अपने jsonb

— ted

1

@ सच है। हालांकि, इस उत्तर को लिखने के समय जो वास्तव में उपलब्ध नहीं था। साथ ही, यह प्रश्न MySQL का संदर्भ देता है जिसमें क्षमता मौजूद नहीं है।

— कॉलिन एम

3

@ कोलिनम, हां, मुझे एहसास है कि मेरी टिप्पणी आपकी पोस्ट से 3 साल छोटी है। मैंने इसे छोड़ दिया, क्योंकि यह मददगार हो सकता है और दूसरों के लिए निर्णय लेने वाला हो सकता है। MySQL के संदर्भ के लिए: सच हो सकता है, लेकिन "For relational databases"आपके जवाब में है = P

— ted

69

ज्यादातर चीजों की तरह "यह निर्भर करता है"। कॉलम या JSON में डेटा स्टोर करना अपने आप में सही या गलत / अच्छा या बुरा नहीं है। यह इस पर निर्भर करता है कि आपको बाद में इसके साथ क्या करना है। इस डेटा तक पहुंचने का आपका अनुमानित तरीका क्या है? क्या आपको संदर्भ अन्य डेटा पार करने की आवश्यकता होगी?

अन्य लोगों ने बहुत अच्छी तरह से उत्तर दिया है कि तकनीकी व्यापार क्या हैं।

बहुत से लोगों ने चर्चा नहीं की है कि समय के साथ आपका ऐप और सुविधाएँ विकसित होती हैं और यह डेटा संग्रहण निर्णय आपकी टीम को कैसे प्रभावित करता है।

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

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

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

JSON क्षेत्र इस और उस के छोटे टुकड़ों के लिए कबाड़ दराज बन गया। डेटाबेस स्तर पर कोई डेटा सत्यापन, दस्तावेजों के बीच कोई संगतता या अखंडता नहीं। इसने उस सभी जिम्मेदारी को पारंपरिक स्तंभों से कठिन प्रकार और बाधा की जाँच करने के बजाय अनुप्रयोग में धकेल दिया।

पीछे देखते हुए, JSON ने हमें बहुत तेज़ी से पुनरावृति करने और दरवाजे से कुछ बाहर निकालने की अनुमति दी। वह बहुत अच्छा था। हालांकि हम एक निश्चित टीम के आकार तक पहुंचने के बाद यह लचीलापन है कि हमें तकनीकी ऋण की एक लंबी रस्सी के साथ खुद को लटकाए रखने की अनुमति दी, जो बाद में सुविधा विकास प्रगति को धीमा कर दिया। सावधानी से प्रयोग करें।

अपने डेटा की प्रकृति क्या है, इसके बारे में लंबा और कठिन सोचें। यह आपके ऐप की नींव है। समय के साथ डेटा का उपयोग कैसे किया जाएगा। और यह कैसे बदलें संभावना है?

— Homan
स्रोत

7

"यह लचीलापन भी हमें तकनीकी ऋण की लंबी रस्सी के साथ खुद को लटका देने की अनुमति देता है" बहुत अच्छा रूपक!

— एंटोनी गैलिक्स

कई वर्षों के विकास और अलग-अलग लोगों के साथ काम करने के बाद, अगर मुझे इस विषय के बारे में लिखना चाहिए तो मैं वही लिखूंगा। अब बहुत सारे डेवलपर्स हैं, जहां उनमें से कई सालों के अनुभव के साथ भी वास्तव में ऊपर स्तर पर नहीं हैं। हमें हर चीज को सरल रखना है और मेरे लिए 2 चीजें हैं जिन पर हमें हमेशा विचार करना है कि "ढाँचा" सफल हो सकता है कोड की स्थिरता और स्थिरता है।

— जॉनीजैक्स

27

बस इसे उतारा जा रहा है, लेकिन वर्डप्रेस में इस तरह के सामान के लिए एक संरचना है (कम से कम वर्डप्रेस पहला स्थान था जिसे मैंने इसे देखा था, यह संभवतः कहीं और उत्पन्न हुआ था)।

यह असीम कुंजी की अनुमति देता है, और JSON बूँद का उपयोग करने की तुलना में खोज करने के लिए तेज़ है, लेकिन NoSQL समाधानों में से कुछ के रूप में तेज़ नहीं है।

uid   |   meta_key    |   meta_val
----------------------------------
1         name            Frank
1         age             12
2         name            Jeremiah
3         fav_food        pizza
.................

संपादित करें

इतिहास / एकाधिक कुंजी संग्रहीत करने के लिए

uid   | meta_id    |   meta_key    |   meta_val
----------------------------------------------------
1        1             name            Frank
1        2             name            John
1        3             age             12
2        4             name            Jeremiah
3        5             fav_food        pizza
.................

और कुछ इस तरह से क्वेरी करें:

select meta_val from `table` where meta_key = 'name' and uid = 1 order by meta_id desc

— एडम
स्रोत

1

मुझे यह देखने के लिए उत्सुक होना चाहिए कि क्या NoSQL समाधान वास्तव में एक इंडेक्स क्वेरी की तुलना में ठीक से इंडेक्स कुंजी पर बेहतर प्रदर्शन करता है। मुझे संदेह है कि यह इस तरह के 1-स्तरीय उदाहरण पर कम या ज्यादा होना चाहिए।

— ब्रूनो

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

— शुक्लसंनिध्य

@Sann, यदि आप JSON में पुराने मूल्य को रखना चाहते हैं, तो आपको कुंजी का नाम भी बदलना होगा: आप EAV के साथ कर सकते हैं (जो कि यह उदाहरण है) या JSON। यह विशेष रूप से अलग नहीं है।

— ब्रूनो

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

— एडम

सुनिश्चित करें कि आपके पास डुप्लिकेट कुंजियाँ नहीं हो सकती हैं, लेकिन उस कुंजी के साथ संबद्ध एक सरणी हो सकती है। emailidमेरे प्रश्न में दिए गए उदाहरण में कुंजी की जाँच करें ।

— शुक्लसंनिध्य

13

दृष्टिकोण का दोष यह है कि आपने क्या उल्लेख किया है:

यह चीजों को खोजने के लिए बहुत धीमा कर देता है, क्योंकि हर बार आपको इस पर एक पाठ-खोज करने की आवश्यकता होती है।

इसके बजाय प्रति स्तंभ मान पूरे स्ट्रिंग से मेल खाता है।

आपका दृष्टिकोण (JSON आधारित डेटा) उन डेटा के लिए ठीक है जिन्हें आपको खोज करने की आवश्यकता नहीं है, और बस अपने सामान्य डेटा के साथ प्रदर्शित करने की आवश्यकता है।

संपादित करें: केवल स्पष्ट करने के लिए, ऊपर क्लासिक रिलेशनल डेटाबेस के लिए जाता है। NoSQL आंतरिक रूप से JSON का उपयोग करते हैं, और यदि वांछित व्यवहार है तो संभवतः एक बेहतर विकल्प है।

— निक एंड्रियोपोलोस
स्रोत

1

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

— शुक्लसंनिध्य

4

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

— निक एंड्रियोपोलोस

9

असल में, आपके द्वारा उपयोग किए जा रहे पहले मॉडल को दस्तावेज़-आधारित संग्रहण कहा जाता है। MongoDB और CouchDB जैसे लोकप्रिय NoSQL दस्तावेज़-आधारित डेटाबेस पर आपकी नज़र होनी चाहिए । मूल रूप से, दस्तावेज़ आधारित db में, आप डेटा को json फ़ाइलों में संग्रहीत करते हैं और फिर आप इन json फ़ाइलों पर क्वेरी कर सकते हैं।

दूसरा मॉडल लोकप्रिय रिलेशनल डेटाबेस संरचना है।

यदि आप MySql जैसे रिलेशनल डेटाबेस का उपयोग करना चाहते हैं तो मैं आपको केवल दूसरे मॉडल का उपयोग करने का सुझाव दूंगा। MySql का उपयोग करने और पहले मॉडल के रूप में डेटा संग्रहीत करने का कोई मतलब नहीं है ।

यदि आप पहले मॉडल का उपयोग करते हैं , तो आपके दूसरे प्रश्न का उत्तर देने के लिए, 'foo' जैसे नाम को क्वेरी करने का कोई तरीका नहीं है ।

— गिरीश
स्रोत

क्या दोनों मॉडलों का उपयोग करना बुद्धिमान है? डेटा के लिए कुंजी-प्रति-स्तंभ जो मुझे खोजनी है और दूसरों के लिए JSON (उसी डेटाबेस में)?

— शुक्लसंनिध्य

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

— गिरीश

जब अतिरेक डेटा छोटा होता है, तब अतिरेक महंगा नहीं होता, कहते हैं, केवल दो फ़ील्ड हैं जिन पर मुझे खोज करने की आवश्यकता है, इसलिए मैं उनके लिए दो नए कॉलम बनाता हूं, [हो सकता है] उन्हें मेरे JSON डेटा से हटा दें [/ हो सकता है] । यह महंगा दोहराव नहीं होगा?

— शुक्लसंनिध्य

यदि आप प्रदर्शन देख रहे हैं, तो MongoDB और CouchDB MySql की तुलना में तेजी से पढ़ने और लिखने का संचालन प्रदान करते हैं क्योंकि वे रिलेशनल डेटाबेस में बहुत सारी सुविधाएँ प्रदान नहीं करते हैं जो कि अधिकांश उपयोग के मामलों में आवश्यक नहीं हैं।

— गिरीश

एक एपीआई से JSON ऑब्जेक्ट्स / कॉलबैक को संग्रहीत करने में लाभ नहीं हो सकता है? उदाहरण के लिए, URL, अंगूठे आदि के लिए youtube के एपीआई को कॉल करने के बजाय, आप JSON ऑब्जेक्ट के लिए अपने स्थानीय DB (mysql, lite, आदि) को क्वेरी कर सकते हैं? मुझे नहीं पता, मुझे इससे कोई मतलब नहीं है, खासकर यदि आप कैश करने की कोशिश कर रहे हैं या ऐप तेजी से चला रहे हैं। लेकिन मैं कोई पेशेवर नहीं हूँ: /

— markbratanov

4

ऐसा लगता है कि आप मुख्य रूप से संकोच कर रहे हैं कि संबंधपरक मॉडल का उपयोग करें या नहीं।

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

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

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

यदि आप PostgreSQL का उपयोग कर रहे थे, तो आप संभवतः दोनों दुनिया के सर्वश्रेष्ठ प्राप्त कर सकते थे। (यह वास्तव में यहां डेटा की वास्तविक संरचना पर निर्भर करता है ... MySQL जरूरी गलत विकल्प भी नहीं है, और NoSQL विकल्प रुचि का हो सकता है, मैं सिर्फ विकल्प सुझा रहा हूं।)

वास्तव में, PostgreSQL (अपरिवर्तनीय) कार्यों पर इंडेक्स का निर्माण कर सकता है (जो MySQL मैं अब तक नहीं जानता) और हाल के संस्करणों में, आप सीधे JSON डेटा पर PLV8 का उपयोग ब्याज के विशिष्ट JSON तत्वों पर इंडेक्स बनाने के लिए कर सकते हैं , जो बेहतर होगा उस डेटा को खोजते समय आपके प्रश्नों की गति।

संपादित करें:

चूंकि बहुत अधिक कॉलम नहीं होंगे, जिस पर मुझे खोज करने की आवश्यकता है, क्या दोनों मॉडलों का उपयोग करना बुद्धिमान है? डेटा के लिए कुंजी-प्रति-स्तंभ जिसे मुझे खोजना है और दूसरों के लिए JSON (उसी MySQL डेटाबेस में)?

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

इसे प्राप्त करने का एक अच्छा तरीका यह होगा कि जब भी कोई अपडेट या इंसर्ट किया जाए तो डेटाबेस सर्वर के भीतर एक संग्रहीत कार्यविधि को चलाकर एक ट्रिगर को स्वचालित अपडेट किया जाए। जहां तक मुझे जानकारी है, MySQL स्टोर की गई प्रक्रिया भाषा में शायद JSON प्रसंस्करण के किसी भी प्रकार के समर्थन की कमी है। PLV8 समर्थन के साथ फिर से PostgreSQL (और संभवतः अधिक लचीली संग्रहीत कार्यविधि भाषाओं के साथ अन्य RDBMS) अधिक उपयोगी होना चाहिए (एक ट्रिगर का उपयोग करके अपने रिलेशनल कॉलम को स्वचालित रूप से अपडेट करना काफी उसी तरह से एक इंडेक्स को अपडेट करने के समान है)।

— ब्रूनो
स्रोत

ऊपर मैंने जो कहा, इसके अलावा, यह PostgreSQL 9.4 और इसके बाद के संस्करण में JSONB डेटाटाइप के लिए ऑपरेटरों को देखने के लायक हो सकता है।

— ब्रूनो

1

मेज पर कुछ समय के लिए एक उपरि होगी। OLAP के लिए कहते हैं। अगर मेरे पास दो टेबल हैं तो एक है ORDERS टेबल और दूसरा है ORDER_DETAILS। सभी आदेश विवरण प्राप्त करने के लिए, हमें दो तालिकाओं में शामिल होना होगा, जिससे क्वेरी धीमी हो जाएगी जब तालिकाओं में कोई भी पंक्तियाँ लाखों में कहती हैं या नहीं .. बायाँ / दाएँ जुड़ना भीतरी जुड़ने की तुलना में बहुत धीमा है। मुझे लगता है कि अगर हम संबंधित ORDERS प्रविष्टि में JSON स्ट्रिंग / ऑब्जेक्ट जोड़ते हैं तो JOIN से बचा जाएगा। जोड़ें रिपोर्ट पीढ़ी तेज हो जाएगा ...

— रवींद्र
स्रोत

1

संक्षिप्त उत्तर जो आपको उनके बीच मिलाना है, डेटा के लिए json का उपयोग करें जो आप उनके साथ संपर्क डेटा, पता, उत्पाद चर जैसे संबंध बनाने के लिए नहीं जा रहे हैं

— अहमदफ्राइजे आ
स्रोत

0

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

db.mycollection.find(
    {
      name: 'sann'
    }
)

— क्रिस एल
स्रोत

2

जिज्ञासा से बाहर, आपने क्या माना कि उसका मॉडल गैर-संबंधपरक है। उन्होंने जो जानकारी ऊपर दी वह मेरे लिए बहुत ही प्रासंगिक है।

— कॉलिन एम

0

जैसा कि अन्य ने बताया है कि क्वेरी धीमी होगी। मैं इसके द्वारा क्वेरी करने के लिए कम से कम '_ID' कॉलम जोड़ने का सुझाव दूंगा।

— पैंट
स्रोत