MySQL में JSON के रूप में डेटा संग्रहीत करना

Question

मुझे लगा कि यह करने के लिए एक n00b बात थी। और, इसलिए, मैंने इसे कभी नहीं किया है। तब मैंने देखा कि FriendFeed ने ऐसा किया और वास्तव में उनके DB पैमाने को बेहतर बनाया और विलंबता को कम किया। मैं उत्सुक हूँ अगर मुझे यह करना चाहिए। और, यदि हां, तो इसे करने का सही तरीका क्या है?

मूल रूप से, MySQL में सब कुछ स्टोर करने का तरीका जानने के लिए एक अच्छी जगह क्या है जो एक CouchDB प्रकार DB के रूप में है? JSON के रूप में सब कुछ संग्रहीत करना ऐसा लगता है कि यह आसान और तेज होगा (निर्माण नहीं, कम विलंबता)।

इसके अलावा, क्या डीबी पर JSON के रूप में संग्रहीत चीजों को संपादित करना, हटाना, आदि करना आसान है?

Comments

संदर्भ के लिए, मेरा मानना है कि यह MySQL में JSON के प्रयोग पर FriendFeed की चर्चा है: backchannel.org/blog/friendfeed-schemaless-mysql

— dimo414

MySQL 5.7 अब एक देशी JSON डेटास्टोर का समर्थन करता है।

— ईक्यू

Answer 1

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

मत करो।

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

Comments

हाँ, मानगो में देख रहे हैं, और इसके लिए एक विस्तार है और DB लेनदेन के लिए वास्तविक वाक्यविन्यास MySQL की तुलना में आसान लगता है और इसके साथ काम करने वाले कुल मिलाकर आसान लगता है कि couchDB। धन्यवाद, मुझे लगता है कि मैं MongoDB :)

— ऑस्कर गोडसन

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

— अंक

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

— निक बेडफोर्ड

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

— rjarmstrong

यह बहुत कम-सलाह है, शायद किसी ऐसे व्यक्ति द्वारा जो स्टैक एक्सचेंज पर बहुत अधिक समय खर्च करता है? जब मेरे पास 100 क्षेत्रों के साथ एक रिकॉर्ड होता है जिसे मैं संग्रहीत करना चाहता हूं और मुझे केवल 3 या 4 फ़ील्ड पर खोज करने की आवश्यकता है, तो 100 फ़ील्ड के साथ एक तालिका बनाना निरर्थक है। आप JSON में 1 फ़ील्ड में संग्रहीत अपनी संपूर्ण पता पुस्तिका के साथ एक ग्राहक रिकॉर्ड संग्रहीत कर सकते हैं, और रिकॉर्ड्स की खोज करने के लिए उपयोग करने के लिए अन्य फ़ील्ड के रूप में ग्राहक आईडी, अंतिम नाम, कंपनी को जोड़ सकते हैं। यह है। विशाल समय बचाने वाला।

— डेनियल

Answer 2

हर कोई टिप्पणी कर रहा है कि यह गलत कोण से आ रहा है, यह एक संबंधपरक DB में PHP के माध्यम से JSON कोड को स्टोर करने के लिए ठीक है और यह वास्तव में इस तरह के जटिल डेटा को लोड और प्रदर्शित करने के लिए तेज़ होगा, हालांकि आपके पास डिज़ाइन विचार होंगे जैसे खोज करना, अनुक्रमण करना आदि।

ऐसा करने का सबसे अच्छा तरीका हाइब्रिड डेटा का उपयोग करना है, उदाहरण के लिए यदि आपको डेटाइम MySQL (प्रदर्शन ट्यून) के आधार पर खोज करने की आवश्यकता है, तो PHP की तुलना में बहुत तेज़ होने वाला है और कुछ स्थानों की खोज के लिए जैसे MySQL भी बहुत कुछ होना चाहिए अधिक तेज़ (नोटिस एक्सेस नहीं कर रहा है)। डेटा जिसे आपको खोज करने की आवश्यकता नहीं है उसे तब JSON, BLOB या किसी अन्य प्रारूप में संग्रहीत किया जा सकता है जिसे आप वास्तव में आवश्यक समझते हैं।

आपके द्वारा उपयोग किए जाने वाले डेटा को बहुत आसानी से JSON के रूप में संग्रहीत किया जाता है उदाहरण के लिए एक मूल प्रति-केस इनवॉइस सिस्टम। RDBMS से उन्हें बहुत अधिक लाभ नहीं होता है, और यदि आपको सही HTML फॉर्म संरचना मिलती है, तो JSON में बस json_encoding ($ _ POST ['entires']) में संग्रहीत किया जा सकता है।

मुझे खुशी है कि आप MongoDB का उपयोग करके खुश हैं और मुझे आशा है कि यह आपकी अच्छी तरह से सेवा कर रहा है, लेकिन यह मत सोचिए कि MySQL हमेशा आपके रडार से दूर रहने वाली है, क्योंकि आपकी ऐप जटिलता बढ़ने पर आपको अच्छी तरह से RDBMS की आवश्यकता हो सकती है कुछ कार्यक्षमता और विशेषताएं (भले ही यह संग्रहीत डेटा या व्यावसायिक रिपोर्टिंग को रिटायर करने के लिए है)

Comments

-1 के लिए "एक रिलेशनल DB में PHP के माध्यम से JSON कोड को स्टोर करना ठीक है" - स्टोरिंग JSON (जो कि एक गैर-परमाणु डेटा के रूप में एक संपूर्ण इकाई का प्रतिनिधित्व कर सकता है) रिलेशनल मॉडल का उल्लंघन करता है और 1NF को रोकता है। इसके अलावा, मेट्रिक्स के बिना प्रदर्शन के बारे में व्यापक दावे न करें, ताकि आप बैकअप ले सकें।

— ऋषि जेरार्ड

जैसा कि उल्लेख किया गया है कि यह इस बात पर निर्भर करता है कि आप क्या कर रहे हैं, यानी इनवॉइस के लिए आपको वास्तव में प्रत्येक प्रविष्टि को अलग से संग्रहीत करने की आवश्यकता है? नहीं, आपकी टिप्पणी ऐसी है जैसे आप जानते हैं, लेकिन 1NF हर क्षेत्र के लिए नहीं है या BLOB और पाठ प्रकार नहीं होंगे ... यह एक उत्पादन प्रणाली के लिए शुद्ध बकवास है, आपको केवल उस चीज़ को अनुकूलित करने की आवश्यकता है जिसे आपको खोजने के लिए आवश्यक है यानी कुछ डेटा पर दिनांक, कुंजियाँ और सेट अप इंडेक्स। मैंने यह नहीं कहा कि सब कुछ JSON के रूप में संग्रहीत करें, मैंने कहा कि JSON के रूप में कुछ डेटा संग्रहीत करें यदि यह आपकी समस्या को हल करने में मदद करता है।

— लुईस रिचर्ड फिलिप काउल्स

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

— ऋषि जेरार्ड

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

— लुईस रिचर्ड फिलिप काउल्स

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

— हेरोसेलोहिम

Answer 3

MySQL 5.7 अब एक देशी JSON डेटा प्रकार का समर्थन करता है जो MongoDB और अन्य योजनाबद्ध दस्तावेज़ डेटा स्टोर के समान है:

JSON समर्थन करते हैं

MySQL 5.7.8 के साथ शुरू, MySQL एक देशी JSON प्रकार का समर्थन करता है। JSON मूल्यों को स्ट्रिंग के रूप में संग्रहीत नहीं किया जाता है, इसके बजाय एक आंतरिक बाइनरी प्रारूप का उपयोग किया जाता है जो दस्तावेज़ तत्वों को त्वरित पढ़ने की अनुमति देता है। JSON कॉलम में संग्रहीत JSON दस्तावेज़ स्वचालित रूप से मान्य किए जाते हैं जब भी उन्हें डाला जाता है या अद्यतन किया जाता है, तो एक अमान्य दस्तावेज़ त्रुटि उत्पन्न करता है। JSON दस्तावेज़ों को निर्माण पर सामान्यीकृत किया जाता है, और उनकी तुलना अधिकांश संचालकों जैसे =, <, <=>,> = =, <>; =; और <=> के रूप में की जाती है; JSON मूल्यों की तुलना करते समय MySQL के बाद समर्थित ऑपरेटरों और साथ ही पूर्ववर्ती और अन्य नियमों के बारे में जानकारी के लिए, JSON मानों की तुलना और आदेश देखें।

MySQL 5.7.8 भी JSON मानों के साथ काम करने के लिए कई कार्यों का परिचय देता है। इन कार्यों में यहाँ सूचीबद्ध लोग शामिल हैं:

1. JSON मान बनाने वाले कार्य: JSON_ARRAY (), JSON_MERGE (), और JSON_OBJECT ()। खंड 12.16.2, "कार्य जो JSON मान बनाते हैं" देखें।
2. JSON मानों को खोजने वाले फ़ंक्शंस: JSON_CONTAINS (), JSON_CONTAINS_PATH (), JSON_EXTRACT (), JSON_KEYS (), और JSON_CARTACH ()। धारा 12.16.3, "कार्य जो JSON मान खोजते हैं" देखें।
3. JSON मानों को संशोधित करने वाले कार्य: JSON_APPEND (), JSON_ARRAY_APPEND (), JSON_ARRAY_INSERT (), JSON_INSERT (), JSON_QURAE (), JSON_REMOVE (), JSON_REPLACE (), JSON_REPLACE (), JSON_SET खंड 12.16.4, "कार्य जो जेन्सन मूल्यों को संशोधित करते हैं" देखें।
4. JSON मानों के बारे में जानकारी प्रदान करने वाले कार्य: JSON_DEPTH (), JSON_LENGTH (), JSON_TYPE (), और JSON_VALID ()। खंड 12.16.5, "कार्य जो JSON मान गुण लौटाता है" देखें।

MySQL 5.7.9 और बाद में, आप JSON_EXTRACT (स्तंभ, पथ) के लिए शॉर्टहैंड के रूप में कॉलम-> पथ का उपयोग कर सकते हैं। यह एक स्तंभ के लिए एक उपनाम के रूप में काम करता है जहां एक स्तंभ पहचानकर्ता SQL कथन में हो सकता है, जिसमें WHERE, ORDER BY और GROUP BY खंड शामिल हैं। इसमें SELECT, UPDATE, DELETE, CREATE TABLE और अन्य SQL स्टेटमेंट शामिल हैं। बाएं हाथ की ओर एक JSON कॉलम पहचानकर्ता होना चाहिए (और अन्य नहीं)। दाहिने हाथ की ओर एक उद्धृत JSON पथ अभिव्यक्ति है, जिसे स्तंभ मान के रूप में लौटाए गए JSON दस्तावेज़ के विरुद्ध मूल्यांकन किया जाता है।

के बारे में अधिक जानकारी के लिए खंड 12.16.3, "कार्य जो JSON मान खोजता है" देखें -> और JSON_EXTRACT ()। MySQL 5.7 में JSON पथ समर्थन के बारे में जानकारी के लिए, JSON मान खोज और संशोधित करना देखें। सेकंडरी इंडेक्स और वर्चुअल जेनरेट किए गए कॉलम भी देखें।

और जानकारी:

https://dev.mysql.com/doc/refman/5.7/en/json.html

Answer 4

जब यह भंडारण के लिए नीचे आता है तो json अक्षर कुछ खास नहीं हैं, जैसे कि वर्ण

{, }, [, ], ', a-z,0-9 .... वास्तव में कुछ खास नहीं कर रहे हैं और पाठ के रूप में संग्रहीत किया जा सकता।

आपकी पहली समस्या यह है

{profile_id: 22, उपयोगकर्ता नाम: 'रॉबर्ट', पासवर्ड: 'skhgeeht893htgn34ythger')}

जब तक आपके पास अपनी खुद की कार्यवाही नहीं थी और mysql के लिए एक jsondecode विकसित नहीं किया था, तब तक डेटाबेस में संग्रहीत किया जाना इतना आसान नहीं है

UPDATE users SET JSON(user_data,'username') = 'New User';

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

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

Comments

क्या डेटाबेस में json string स्टोर करना काफी अच्छा है, जब मैं इसे अपडेट नहीं करता? मैं सिर्फ LIKE का उपयोग करके json डेटा पर एक सामान्य खोज करना चाहता हूँ। मैं देख रहा हूँ कि Wordpress भी डेटाबेस में json string के रूप में प्लगइन मेटाडेटा को संग्रहीत करता है।

— shasi kant

@ शशिकांत, यदि आप JSON डेटा में मान खोज रहे हैं, तो मैं एक बेहतर दृष्टिकोण की तलाश करूंगा

— Kirby

Answer 5

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

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

SELECT
    SUBSTRING(
        REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', ''),
        LOCATE(
            CONCAT('myfield', ':'),
            REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', '')
        ) + CHAR_LENGTH(CONCAT('myfield', ':')),
        LOCATE(
            ',',
            SUBSTRING(
                REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', ''),
                LOCATE(
                    CONCAT('myfield', ':'),
                    REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', '')
                ) + CHAR_LENGTH(CONCAT('myfield', ':'))
            )
        ) - 1
    )
    AS myfield
FROM mytable WHERE id = '3435'

Comments

आप इस सर्वर साइड थियो को क्वेरी नहीं करेंगे। यह एक ब्लॉब को स्टोर करने और इसे क्लाइंट की तरफ वापस लाने के लिए होगा। तब आप इसे क्वेरी करने के लिए JS का उपयोग करेंगे। यह एक लंबे समय से पहले था :) मैं इस सामान के लिए MongoDB में स्थानांतरित कर दिया गया है :) इस सुंदर चालाक क्वेरी थो के लिए अपवोट।

— ऑस्कर गोडसन

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

— जॉन

Answer 6

यह वास्तव में आपके उपयोग के मामले पर निर्भर करता है। यदि आप ऐसी जानकारी संग्रहीत कर रहे हैं, जिसका रिपोर्टिंग में कोई मूल्य नहीं है, और अन्य तालिकाओं के साथ JOIN के माध्यम से क्वेरी नहीं की जाएगी, तो यह आपके लिए JSON के रूप में एन्कोड किए गए एकल पाठ फ़ील्ड में आपके डेटा को संग्रहीत करने के लिए समझ में आ सकता है।

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

Comments

मेरे विचार से भी। यदि उसका डेटा जो कभी भी शामिल नहीं है / खोजा गया है या यहां तक ​​कि शायद ही कभी अपडेट किया गया है तो एक TEXT फ़ील्ड में json का उपयोग क्यों नहीं करते हैं। इसका एक अच्छा उदाहरण एक खाद्य तालिका है जहां प्रत्येक खाद्य पदार्थ को पोषण संबंधी जानकारी संग्रहीत करने की आवश्यकता होगी। सर्विंग साइज़, प्रोटिन, कार्ब्स, फैट टोटल, फैट सिट वगैरह वगैरह। लेकिन इतना ही नहीं, आपको वैल्यू (0.2) और उस यूनिट को स्टोर करना होगा, जिसे जी (ऑज़, फ़्ल ओज़, एमएल) में मापा गया था। यह देखते हुए कि यह डेटा है (जो आप मेरे द्वारा किए जा रहे हैं पर निर्भर करता है) को खोजने की आवश्यकता नहीं है, मैं कहूंगा कि 1 TEXT बनाम 16 int / varchar / enum कॉलम एक अच्छा व्यापार है।

— ब्रैड मूर

बिल्कुल सही!!! यह उपयोगी है जब आपको चर और / या अज्ञात डेटा संरचना को स्टोर करना होगा जिसे आप SQL के साथ फ़िल्टर करने की योजना बिल्कुल नहीं बनाते हैं। डेटा को बस के रूप में संग्रहीत किया जाता है और कोई और (ऐप कोड) संरचना को जान सकता है और इसके साथ क्या करना है।

— डेलमो

Answer 7

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

सबसे पहले, RDBMS में JSON को संग्रहीत करने में बेहतर समर्थन है। आप PostgreSQL पर स्विच करने पर विचार कर सकते हैं (हालांकि MySQL ने JSON को v5.7.7 से समर्थन दिया है)। PostgreSQL MySQL के रूप में बहुत समान SQL कमांड का उपयोग करता है, सिवाय इसके कि वे अधिक फ़ंक्शन का समर्थन करते हैं। उनके द्वारा जोड़े गए कार्यों में से एक यह है कि वे JSON डेटा प्रकार प्रदान करते हैं और अब आप JSON को संग्रहीत करने में सक्षम हैं। ( इस पर कुछ संदर्भ ) यदि आप अपने प्रोग्राम में सीधे क्वेरी नहीं बना रहे हैं, उदाहरण के लिए, लारावेल में php या वाक्पटु में PDO का उपयोग करना, आपको बस अपने सर्वर पर PostgreSQL को स्थापित करने और कनेक्शन कनेक्शन सेटिंग्स बदलने की आवश्यकता है। आपको अपना कोड बदलने की भी आवश्यकता नहीं है।

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

उदाहरण के लिए, ब्लॉग पोस्ट के टैग को संग्रहीत करने के लिए, आम तौर पर आपको ब्लॉग पोस्ट के लिए एक तालिका, टैग की एक तालिका और एक मिलान तालिका होनी चाहिए। इसलिए, जब उपयोगकर्ता किसी पोस्ट को संपादित करना चाहता है और आपको उस पोस्ट से संबंधित कौन सा टैग प्रदर्शित करना है, तो आपको 3 तालिकाओं की आवश्यकता होगी। यदि आपकी मिलान तालिका / टैग तालिका लंबी है, तो यह प्रदर्शन को बहुत नुकसान पहुंचाएगा।

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

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

Answer 8

मैं कहूंगा कि इस पर विचार करने के केवल दो कारण हैं:

• सामान्यीकृत दृष्टिकोण के साथ प्रदर्शन अभी पर्याप्त नहीं है
• आप आसानी से अपने विशेष रूप से तरल / लचीला / बदलते डेटा को मॉडल नहीं कर सकते

मैंने यहाँ अपने दृष्टिकोण के बारे में थोड़ा लिखा है:

NoSQL डेटा स्टोर का उपयोग करके आपको किन स्केलेबिलिटी समस्याओं का सामना करना पड़ा है?

(शीर्ष उत्तर देखें)

यहां तक ​​कि JSON काफी तेज नहीं था, इसलिए हमने एक कस्टम-टेक्स्ट-प्रारूप दृष्टिकोण का उपयोग किया। काम किया / हमारे लिए अच्छी तरह से काम करना जारी रखता है।

वहाँ एक कारण तुम MongoDB की तरह कुछ का उपयोग नहीं कर रहे हैं? (MySQL "आवश्यक" हो सकता है; बस जिज्ञासु)

Answer 9

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

2014 में हमारे पास कई डेटाबेस सर्वर तक पहुंच है जो विशिष्ट प्रकार के डेटा को असाधारण रूप से अच्छी तरह से संभालते हैं।

• मोंगो (दस्तावेज़ भंडारण)
• रेडिस (की-वैल्यू डेटा स्टोरेज)
• MySQL / Maria / PostgreSQL / Oracle / etc (संबंधपरक डेटा)
• काउचडीबी (JSON)

मुझे यकीन है कि मैंने कुछ अन्य लोगों को याद किया, जैसे कि RabbirMQ और Cassandra। मेरा कहना है, आपके द्वारा संग्रहित डेटा के लिए सही उपकरण का उपयोग करें।

यदि आपके एप्लिकेशन को विभिन्न प्रकार के डेटा के संग्रहण और पुनर्प्राप्ति की आवश्यकता होती है, तो वास्तव में तेजी से, (और जो नहीं करता है) एक आवेदन के लिए कई डेटा स्रोतों का उपयोग करने से कतराते नहीं हैं। अधिकांश लोकप्रिय वेब फ्रेमवर्क कई डेटा स्रोतों (रेल, Django, Grails, Cake, Zend, आदि) के लिए समर्थन प्रदान करते हैं। यह रणनीति अनुप्रयोग के एक विशिष्ट क्षेत्र, ORM या अनुप्रयोग के डेटा स्रोत इंटरफ़ेस की जटिलता को सीमित करती है।

Comments

आपकी राय में RabbitMQ एक डेटाबेस सर्वर या किसी प्रकार का है? मैं कहूंगा कि यह एक संदेश-उन्मुख मिडलवेयर है जिसमें किसी भी संदेश को न खोने के लिए एक अच्छा सा हठ सुविधा है, लेकिन कुछ भी नहीं जिसके साथ मैं डेटा को बचाऊंगा। केवल मेरे दो सेंट्स।

— ओसिरिज

@Oiriz: आप सही हैं। मुझे शायद इस चर्चा में शामिल नहीं करना चाहिए था।

— चेडरमोनी

Answer 10

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

सेव / अपडेट फंक्शन

function save($uid, $key, $val){
 global $dbh; // The PDO object
 $sql = $dbh->prepare("SELECT `json` FROM users WHERE `id`=?");
 $sql->execute(array($uid));
 $data      = $sql->fetch();
 $arr       = json_decode($data['json'],true);
 $arr[$key] = $val; // Update the value
 $sql=$dbh->prepare("UPDATE `users` SET `json`=? WHERE `id`=?");
 $sql->execute(array(
   json_encode($arr), 
   $uid
 ));
}

जहां $ uid उपयोगकर्ता की आईडी, $ कुंजी है - अपडेट करने के लिए JSON कुंजी और यह $ वैल के रूप में उल्लिखित है ।

मान प्राप्त करें

function get($uid, $key){
 global $dbh;
 $sql = $dbh->prepare("SELECT `json` FROM `users` WHERE `id`=?");
 $sql->execute(array($uid));
 $data = $sql->fetch();
 $arr  = json_decode($data['json'], true);
 return $arr[$key];
}

जहां $ कुंजी JSON सरणी की एक कुंजी है जिसमें से हमें मूल्य की आवश्यकता है।

Comments

यह परस्पर विरोधी मामलों में विफल हो जाता है, क्या होगा यदि आप जिस जसन को पढ़ते हैं, वह किसी अन्य प्रक्रिया से अपडेट हो जाता है, और फिर आप वर्तमान थ्रेड को ओवरराइट करके इसे सहेजते हैं? आपको SELECT FOR UPDATEजैसन डेटा के भीतर ताले की तरह या संस्करण की आवश्यकता हो सकती है ।

— ध्रुवपाठक

@DhruvPathak क्या आप इसका उपयोग करके उत्तर को अपडेट कर सकते हैं SELECT FOR UPDATEताकि यह और बेहतर हो सके। मुझे नहीं पता कि इसका उपयोग कैसे करना है।

— सुबिन

Answer 11

MySQL में JSON के भंडारण के लिए प्रारंभिक समर्थन MySQL 5.7.7 JSON लैब रिलीज़ ( लिनक्स बायनेरी , स्रोत ) में जोड़ा गया है ! लगता है कि रिलीज 2013 में JSON से संबंधित उपयोगकर्ता द्वारा परिभाषित कार्यों की एक श्रृंखला से बढ़ी है ।

यह नवजात मूल JSON समर्थन एक बहुत ही सकारात्मक दिशा में जा रहा है, जिसमें INSERT पर JSON सत्यापन शामिल है, प्रस्तावना में एक लुकअप तालिका सहित एक अनुकूलित बाइनरी स्टोरेज प्रारूप है जो JSN_EXTRACT फ़ंक्शन को हर एक्सेस पर पार्स करने के बजाय बाइनरी लुकअप प्रदर्शन करने की अनुमति देता है। विशिष्ट JSON डेटाटिप्स को संभालने और क्वेरी करने के लिए नए कार्यों का एक पूरा बेड़ा भी है:

CREATE TABLE users (id INT, preferences JSON);

INSERT INTO users VALUES (1, JSN_OBJECT('showSideBar', true, 'fontSize', 12));

SELECT JSN_EXTRACT(preferences, '$.showSideBar') from users;

+--------------------------------------------------+
| id   | JSN_EXTRACT(preferences, '$.showSideBar') |
+--------------------------------------------------+
| 1    | true                                      |
+--------------------------------------------------+

IMHO, ऊपर इस नई कार्यक्षमता के लिए एक महान उपयोग मामला है; कई SQL डेटाबेस में पहले से ही एक उपयोगकर्ता तालिका है और उपयोगकर्ता वरीयताएँ के एक विकसित सेट को समायोजित करने के लिए अंतहीन स्कीमा परिवर्तन करने के बजाय, एक सिंगल JSON कॉलम का एक एकल JOINभाग एकदम सही है। विशेष रूप से यह संभावना नहीं है कि यह कभी भी व्यक्तिगत वस्तुओं के लिए queried की आवश्यकता होगी।

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

Answer 12

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

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

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

Answer 13

JSON PostgreSQL डेटाबेस में भी एक मान्य डेटाटाइप है। हालाँकि, MySQL डेटाबेस ने आधिकारिक तौर पर JSON का अभी तक समर्थन नहीं किया है। लेकिन यह पकाना है: http://mysqlserverteam.com/json-labs-release-native-json-data-type-and-binary-format/

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

Answer 14

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

अगर आपको लगता है कि आप ऐसा कर सकते हैं, तो json का उपयोग करें, क्योंकि आप कर सकते हैं! और, इसे भूल जाओ अगर यह एक गलती थी; अच्छा या बुरा चुनाव करके प्रयास करें, लेकिन कोशिश करें!

कम

एक फ्रेंच उपयोगकर्ता

Comments

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

— डिएगो जैनिक

आप सही हैं, वास्तव में भ्रमित उत्तर दें, उदाहरण दिखा कर अधिक स्पष्ट होना चाहिए। लेकिन, अगर mysql को mongoDB द्वारा प्रतिस्थापित किया जा सकता है, तो json (mongodb के मूल निवासी के रूप में) का उपयोग करना अधिक प्रभावशाली होगा, यदि mysql अनिवार्य है, ठीक है, चलो कुछ दिनों में फिर से प्रयास करें!

— लो

Answer 15

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

Answer 16

आप इस gist का उपयोग कर सकते हैं: https://gist.github.com/AminaG/33d90cb99c26298c48f670b8ffac39c3

इसे सर्वर पर स्थापित करने के बाद (बस रूट विशेषाधिकार की ज़रूरत नहीं है), आप कुछ इस तरह से कर सकते हैं:

select extract_json_value('{"a":["a","2"]}','(/a)')

यह वापस आ जाएगा a 2 । आप JSON के अंदर कुछ भी वापस कर सकते हैं इसका उपयोग करके अच्छा हिस्सा यह है कि यह MySQL 5.1,5.2,5.6 का समर्थन करता है। और आपको सर्वर पर किसी भी बाइनरी को स्थापित करने की आवश्यकता नहीं है।

पुराने प्रोजेक्ट के आधार पर common-schema, लेकिन यह आज भी काम कर रहा है https://code.google.com/archive/p/common-schema/

Comments

gist अब 404 है

— neoDev