जबकि मैं अंततः एक नए, हल्के, और/या तेज़ डीबीएमएस (जैसे उपयुक्त नामित हल्के SQLite या दस्तावेज़-आधारित मोंगो- जिनमें से बाद में इस मुद्दे को प्रस्तुत नहीं करेगा) पर स्विच करने की उम्मीद कर रहा हूं, मैं वर्तमान में चिपक रहा हूं मानक MySQL प्रणाली के लिए। हालांकि मुझे एहसास है कि इस प्रश्न का कोई भी उत्तर राय में से एक हो सकता है, मैं सोच रहा हूं कि एक MySQL [या अन्यथा रिलेशनल-आधारित] डेटाबेस के एक कॉलम में क्रमबद्ध डेटा जैसे सरणी या हैश-मैप को कैसे स्टोर किया जाएगा। अधिकांश डेटा एक्सेस PHP के माध्यम से निष्पादित किया जाएगा, लेकिन मैं डंप किए गए PHP सरणी के सादे-पाठ के बजाय डेटा को एक मानक प्रारूप (यानी JSON या बाइनरी हैश-मैप- अधिमानतः बाद वाला) में संग्रहीत करना चाहता हूं। इसका कारण यह है कि मैं पाइथन, एक संकलित सी/सी++ एप्लिकेशन, या कमांड लाइन से कुछ डेटा क्वेरी कर सकता हूं।

धन्यवाद।

0
terrygarcia 1 फरवरी 2012, 16:46

4 जवाब

सबसे बढ़िया उत्तर

पूर्व चेतावनी: यह केवल मेरी राय है।

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

जब आपको अपने PHP कोड से डेटा को डेटाबेस में संग्रहीत करने की आवश्यकता होती है, तो हैशमैप पास करते हुए, बस अपनी मॉडल परत में संबंधित विधियों/कार्यों को कॉल करें। जब आपको डीबी से डेटा लोड करने की आवश्यकता होती है, तो हैशमैप (या जो भी प्रासंगिक पहचानकर्ता है) की मॉडल परत पासिंग आईडी में संबंधित विधियों/कार्यों को कॉल करें - और हैशपैप वापस प्राप्त करें।

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

2
Aleks G 1 फरवरी 2012, 16:52

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

उदाहरण के लिए, यदि आप अपने JSON को {A: 'valueA', B: 'valueB'} प्रारूप में संग्रहीत करेंगे और सभी दस्तावेज़ प्राप्त करना चाहते हैं जहां B='realvalueB' है, तो आपको प्राप्त करना होगा सभी पंक्तियाँ, उन्हें json_decode के साथ php ऑब्जेक्ट्स में बदलें और तुलना करें... दूसरी ओर, यदि आप MongoDb का उपयोग करते हैं, तो आप एक प्रश्न करेंगे: db.myobjects.find({B:'realvalueB'}) और यह वापस आ जाएगा केवल मिलान किए गए दस्तावेज़। यह बेहतर क्यों है इसका एक सरल उदाहरण था। आप यहां और यहां आप मोंगोडब क्‍वेरी के साथ क्‍या कर सकते हैं।

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

यदि आप MySQL के साथ जाते हैं (क्योंकि यह अधिक परिपक्व है, आप इससे अधिक परिचित हैं आदि) "वास्तविक" संबंधपरक मॉडल के साथ जाना हमेशा अच्छा होता है, लेकिन यदि आपके उपयोग के मामले आपको अनुमति देते हैं तो आप हमेशा कुछ सामान ब्लॉब में डाल सकते हैं। ऐसा करने के लिए।

1
Aleksandar Vucetic 1 फरवरी 2012, 19:20

मैं इसे बिल्कुल भी स्टोर नहीं करूंगा।
इस तरह की अजीब और स्पष्ट रूप से बेकार चीज करने के बजाय मैं डेटा से एक रिलेशनल मॉडल बनाने की कोशिश करूंगा। यह नोएसक्यूएल युग से पहले कई बार किया गया था और निश्चित रूप से एक बार और किया जा सकता है।

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

0
Your Common Sense 1 फरवरी 2012, 16:54

बस MySQL में टेक्स्ट फ़ील्ड का उपयोग करें और json_encode() और json_decode($v, true)। आप उन कार्यों को अपने कोड में लपेटना चाह सकते हैं ताकि जब इस स्टोरेज मॉडल को किसी अन्य के साथ बदलने की आवश्यकता हो तो आप इसे अपनी फाइलों में json_encode और json_decode की सभी घटनाओं को ट्रैक करने के बजाय एक ही स्थान पर कर सकते हैं।

यदि आप वास्तव में विशाल हैश रखना चाहते हैं तो आपको कुछ कॉन्फ़िगरेशन समायोजित करने की आवश्यकता हो सकती है (जैसा कि यहां बताया गया है http://dev.mysql.com/doc/refman/5.0/en/blob.html):

BLOB या TEXT ऑब्जेक्ट का अधिकतम आकार उसके प्रकार से निर्धारित होता है, लेकिन क्लाइंट और सर्वर के बीच वास्तव में आप जो सबसे बड़ा मान संचारित कर सकते हैं, वह उपलब्ध मेमोरी की मात्रा और संचार बफ़र्स के आकार से निर्धारित होता है। आप max_allowed_packet चर के मान को बदलकर संदेश बफ़र का आकार बदल सकते हैं, लेकिन आपको सर्वर और अपने क्लाइंट प्रोग्राम दोनों के लिए ऐसा करना होगा। उदाहरण के लिए, mysql और mysqldump दोनों आपको क्लाइंट-साइड max_allowed_packet मान को बदलने में सक्षम बनाते हैं। खंड 7.9.2, “ट्यूनिंग सर्वर पैरामीटर्स”, खंड 4.5.1, “mysql — MySQL कमांड-लाइन टूल” और खंड 4.5.4, “mysqldump — एक डेटाबेस बैकअप प्रोग्राम” देखें। आप भंडारण आवश्यकताओं के साथ पैकेट आकार और डेटा ऑब्जेक्ट के आकार की तुलना करना चाह सकते हैं, खंड 10.5, "डेटा प्रकार संग्रहण आवश्यकताएँ" देखें।

और स्पष्ट रूप से हैश को सहेजने और पढ़ने के लिए संग्रहीत प्रक्रियाओं का उपयोग करें।

उपरोक्त मानता है कि आप डेटा को केवल स्टोर और पुनर्प्राप्त करना चाहते हैं। यदि आप कोई खोज या एकत्रीकरण करना चाहते हैं तो दूसरा तरीका खोजने का प्रयास करें।

-1
Kamil Szot 1 फरवरी 2012, 17:23