सबसे पहले, आप वास्तव में ऐसा नहीं करना चाहते हैं। RDBMS में एक कॉलम परमाणु होता है, जिसमें इसमें एक और केवल एक जानकारी होती है। एक कॉलम में एक से अधिक डेटा को स्टोर करने का प्रयास करना पहले सामान्य फॉर्म का उल्लंघन है।
यदि आपको इसे बिल्कुल करना है, तो आपको डेटा को एक ऐसे रूप में परिवर्तित करने की आवश्यकता है जिसे डेटा के एक आइटम के रूप में संग्रहीत किया जा सकता है, आमतौर पर एक स्ट्रिंग। आप PHP के serialize() तंत्र, XML पार्सिंग (यदि डेटा एक दस्तावेज़ ट्री होता है), json_encode(), आदि का उपयोग कर सकते हैं।
लेकिन आप ऐसे डेटा को प्रभावी ढंग से कैसे क्वेरी करते हैं? जवाब यह है कि आप नहीं कर सकते।
साथ ही, यदि कोई अन्य व्यक्ति बाद में आपके प्रोजेक्ट को अपने हाथ में लेता है तो आप वास्तव में उन्हें परेशान करने वाले हैं, क्योंकि डेटाबेस में क्रमबद्ध डेटा के साथ काम करना डरावना है। मुझे पता है क्योंकि मुझे ऐसे प्रोजेक्ट विरासत में मिले हैं।
क्या मैंने उल्लेख किया कि आप वास्तव में ऐसा नहीं करना चाहते हैं? आपको अपने डिजाइन पर पुनर्विचार करने की आवश्यकता है ताकि इसे परमाणु पंक्तियों के संदर्भ में अधिक आसानी से संग्रहीत किया जा सके। उदाहरण के लिए, इस डेटा के लिए किसी अन्य तालिका का उपयोग करें और इसे मास्टर रिकॉर्ड से जोड़ने के लिए विदेशी कुंजियों का उपयोग करें। उन्हें किसी कारण से रिलेशनल डेटाबेस कहा जाता है।
अपडेट करें :मुझसे डेटा भंडारण आवश्यकताओं के बारे में पूछा गया है, जैसे कि भंडारण के मामले में एक पंक्ति सस्ती होगी या नहीं। इसका उत्तर है, विशिष्ट मामलों में नहीं, यह नहीं है, और ऐसे मामलों में जहां उत्तर हां है, इसके लिए आप जिस कीमत का भुगतान करते हैं वह भुगतान के लायक नहीं है।
यदि आप 2 कॉलम आश्रित तालिका का उपयोग करते हैं (नमूना से संबंधित रिकॉर्ड की विदेशी कुंजी के लिए 1 कॉलम, एक नमूने के लिए एक) तो प्रत्येक कॉलम को कम से कम 16 बाइट्स की आवश्यकता होगी (एक लॉन्गिंट कुंजी कॉलम के लिए 8 बाइट्स, 8 बाइट्स एक डबल सटीक फ़्लोटिंग पॉइंट नंबर के लिए)। 100 रिकॉर्ड के लिए जो 1600 बाइट्स है (डीबी ओवरहेड को अनदेखा कर रहा है)।
एक क्रमबद्ध स्ट्रिंग के लिए, आप स्ट्रिंग में प्रति वर्ण 1 बाइट सर्वोत्तम स्थिति में संग्रहीत करते हैं। आप यह नहीं जान सकते हैं कि स्ट्रिंग कितनी लंबी होने वाली है, लेकिन अगर हम किसी आकस्मिक संयोग से सभी संग्रहीत डेटा के साथ 100 नमूने मान लेते हैं, तो सभी 10000.00 और 99999.99 के बीच आते हैं और दशमलव बिंदु के बाद केवल 2 अंक होते हैं, तो आप ' प्रति नमूना 8 बाइट्स देख रहे हैं। इस मामले में, आपने जो कुछ भी सहेजा है वह विदेशी कुंजियों का ऊपरी भाग है, इसलिए आवश्यक भंडारण की मात्रा 800 बाइट्स पर आती है।
यह निश्चित रूप से बहुत सारी मान्यताओं पर आधारित है, जैसे कि वर्ण एन्कोडिंग हमेशा प्रति वर्ण 1 बाइट होता है, नमूने बनाने वाले तार कभी भी 8 वर्णों से अधिक लंबे नहीं होते हैं, आदि।
लेकिन निश्चित रूप से डेटा को क्रमबद्ध करने के लिए आप जो भी तंत्र का उपयोग करते हैं उसका ऊपरी भाग भी होता है। सबसे सरल विधि, सीएसवी, का अर्थ है प्रत्येक नमूने के बीच अल्पविराम जोड़ना। यह संग्रहीत स्ट्रिंग में n-1 बाइट्स जोड़ता है। तो उपरोक्त उदाहरण अब 89 9 बाइट्स होगा, और यह सबसे सरल एन्कोडिंग योजना के साथ है। JSON, XML, यहां तक कि PHP क्रमांकन सभी इससे अधिक ओवरहेड वर्ण जोड़ते हैं, और आपके पास जल्द ही ऐसे तार होंगे जो 1600 बाइट्स से अधिक लंबे होंगे। और यह सब 1 बाइट कैरेक्टर एन्कोडिंग की धारणा के साथ है।
यदि आपको नमूनों को अनुक्रमित करने की आवश्यकता है, तो डेटा की आवश्यकताएं स्ट्रिंग्स के मुकाबले और भी अधिक अनुपातहीन रूप से बढ़ेंगी, क्योंकि एक स्ट्रिंग इंडेक्स स्टोरेज के मामले में फ्लोटिंग पॉइंट कॉलम इंडेक्स की तुलना में बहुत अधिक महंगा होगा।
और निश्चित रूप से यदि आपके नमूने अधिक अंक जोड़ना शुरू करते हैं, तो डेटा संग्रहण और बढ़ जाता है। 39281.3392810 स्ट्रिंग के रूप में 8 बाइट्स में संग्रहणीय नहीं होगा, यहां तक कि सर्वोत्तम स्थिति में भी।
और यदि डेटा क्रमबद्ध है तो डेटाबेस हेरफेर नहीं कर सकता है। आप नमूनों को क्रमबद्ध नहीं कर सकते, उन पर किसी भी प्रकार का गणितीय कार्य नहीं कर सकते, डेटाबेस को यह भी नहीं पता कि वे संख्याएँ हैं!
सच कहूं तो, भंडारण इन दिनों हास्यास्पद रूप से सस्ता है, आप छोटी रकम के लिए कई टीबी ड्राइव खरीद सकते हैं। क्या भंडारण वास्तव में इतना महत्वपूर्ण है? जब तक आपके पास करोड़ों रिकॉर्ड नहीं हैं तब तक मुझे संदेह है कि यह है।
हो सकता है कि आप SQL Antipatterns नामक पुस्तक देखना चाहें
