डेटाबेस तालिका के कॉलम में सूची कैसे संग्रहीत करें

Question

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

AKX का समाधान (ऊपर लिंक किया गया) सूची को क्रमबद्ध करना और एक बाइनरी कॉलम में संग्रहीत करना है। लेकिन यह भी असुविधाजनक लगता है क्योंकि इसका मतलब है कि मुझे क्रमबद्धता और डीरिएलाइज़ेशन के बारे में चिंता करनी होगी।

क्या कोई बेहतर उपाय है? अगर वहाँ है कोई बेहतर समाधान है, तो क्यों? ऐसा लगता है कि इस समस्या को समय-समय पर सामने आना चाहिए।

... बस थोड़ा और जानकारी आपको यह बताने के लिए कि मैं कहाँ से आ रहा हूँ। जैसे ही मैंने सामान्य रूप से SQL और डेटाबेस को समझना शुरू कर दिया था, मैं LINQ से SQL में बदल गया था, और इसलिए अब मैं थोड़ा खराब हो गया हूं क्योंकि मैं अपने प्रोग्रामिंग ऑब्जेक्ट मॉडल से निपटने के लिए बिना ऑब्जेक्ट के बारे में सोचने की उम्मीद करता हूं। डेटाबेस में queried या संग्रहीत हैं।

सबको शुक्रीया!

जॉन

अद्यतन करें: तो मुझे मिल रहे उत्तरों की पहली हड़बड़ी में, मैं देख रहा हूँ "आप CSV / XML मार्ग पर जा सकते हैं ... लेकिन नहीं!" तो अब मैं क्यों स्पष्टीकरण के लिए देख रहा हूँ। मुझे कुछ अच्छे संदर्भों की ओर इशारा करें।

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

Answer 1

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

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

आप जिस सिद्धांत का उल्लंघन कर रहे हैं, उसे पहले सामान्य रूप कहा जाता है , जो डेटाबेस सामान्यीकरण का पहला चरण है।

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

मूल रूप से, सामान्यीकरण का पहला नियम (या रूप) बताता है कि आपकी तालिका को किसी संबंध का प्रतिनिधित्व करना चाहिए। इस का मतलब है कि:

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

अंतिम बिंदु स्पष्ट रूप से यहाँ का मुख्य बिंदु है। एसक्यूएल आपके लिए आपके सेट को स्टोर करने के लिए डिज़ाइन किया गया है, न कि आपको "बाल्टी" प्रदान करने के लिए आपको एक सेट खुद को स्टोर करने के लिए। हां, ऐसा करना संभव है। नहीं, दुनिया खत्म नहीं होगी। हालाँकि, आपने पहले से ही SQL को समझने में अपने आप को अपंग कर लिया है और सबसे अच्छे अभ्यास जो इसके साथ-साथ तुरंत एक ORM का उपयोग करके कूदते हैं। LINQ to SQL शानदार है, ठीक उसी तरह जैसे रेखांकन कैलकुलेटर हैं। हालांकि, एक ही नस में, उन्हें यह जानने के विकल्प के रूप में उपयोग नहीं किया जाना चाहिए कि वे वास्तव में काम करने वाली प्रक्रियाओं को कैसे काम करते हैं।

आपकी सूची अब पूरी तरह से "परमाणु" हो सकती है, और यह इस परियोजना के लिए बदल नहीं सकती है। हालाँकि, आप अन्य परियोजनाओं में इसी तरह के काम करने की आदत डाल लेंगे, और आप अंततः (संभवत: जल्दी) एक ऐसे परिदृश्य में भाग लेंगे, जहाँ अब आप अपनी त्वरित-एन-आसान सूची-इन-कॉलम की फिटिंग कर रहे हैं दृष्टिकोण जहां यह पूरी तरह से अनुचित है। जो आप संग्रहीत करने का प्रयास कर रहे हैं, उसके लिए सही तालिका बनाने में बहुत अतिरिक्त काम नहीं है, और जब वे आपके डेटाबेस डिज़ाइन को देखते हैं, तो आपको अन्य SQL डेवलपर्स द्वारा प्राप्त नहीं किया जाएगा। इसके अलावा, LINQ to SQL आपके संबंध को देखने जा रहा है और आपको स्वचालित रूप से आपकी सूची में उचित ऑब्जेक्ट-ओरिएंटेड इंटरफ़ेस देगा । आप ORM द्वारा आपको दी जाने वाली सुविधा को क्यों छोड़ देंगे ताकि आप गैर-मानक और गैर-अनुशंसित डेटाबेस हैकरी कर सकें?

Comments

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

— JnBrymn

मूल रूप से, यह सर्वोत्तम प्रथाओं में संघनित अनुभव के वर्षों में आता है। प्रश्न में मूल प्रिंसिपल को 1 सामान्य फॉर्म के रूप में जाना जाता है ।

— टॉबी

धन्यवाद एडम। बहुत सूचनाप्रद। आपके अंतिम प्रश्न के साथ अच्छा बिंदु।

— JnBrymn

"... [] और आप अन्य SQL डेवलपर्स द्वारा व्युत्पन्न नहीं किया जाएगा जब वे आपके डेटाबेस डिजाइन को देखते हैं।" फर्स्ट नॉर्मल फॉर्म का सम्मान करने के बहुत अच्छे कारण हैं (और आपका जवाब उनका उल्लेख करता है), लेकिन सहकर्मी दबाव / "यह है कि चीजों को इधर-उधर किया जाता है" उनमें से नहीं है।

— लिन

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

— हैकॉन लोट्टविट

Answer 2

आप बस SQL ​​को एक साथ भूल सकते हैं और "NoSQL" दृष्टिकोण के साथ जा सकते हैं। RavenDB , MongoDB और CouchDB कूद संभव समाधान के रूप में मन में। NoSQL दृष्टिकोण के साथ, आप रिलेशनल मॉडल का उपयोग नहीं कर रहे हैं..आप स्कीमा के लिए भी विवश नहीं हैं।

Answer 3

मैंने कई लोगों को ऐसा करते देखा है (यह सबसे अच्छा तरीका नहीं हो सकता है, अगर मैं गलत हूं तो मुझे सुधारें):

उदाहरण में मैं जिस तालिका का उपयोग कर रहा हूं, वह नीचे दी गई है (तालिका में ऐसे उपनाम शामिल हैं जो आपने अपनी विशिष्ट गर्लफ्रेंड को दिए हैं। प्रत्येक प्रेमिका की एक विशिष्ट आईडी होती है)।

nicknames(id,seq_no,names)

मान लीजिए, आप एक आईडी के तहत कई उपनाम संग्रहीत करना चाहते हैं। यही कारण है कि हमने एक seq_noक्षेत्र को शामिल किया है ।

अब, इन मानों को अपनी तालिका में भरें:

(1,1,'sweetheart'), (1,2,'pumpkin'), (2,1,'cutie'), (2,2,'cherry pie')

यदि आप उन सभी नामों को ढूंढना चाहते हैं जो आपने अपनी गर्ल फ्रेंड आईडी 1 को दिए हैं तो आप इसका उपयोग कर सकते हैं:

select names from nicknames where id = 1;

Answer 4

सरल उत्तर: यदि, और केवल यदि, आप निश्चित हैं कि सूची हमेशा एक सूची के रूप में उपयोग की जाएगी, तो सूची को अपने अंत में एक चरित्र (जैसे '\ 0') के साथ जोड़ दें, जिसका उपयोग नहीं किया जाएगा पाठ कभी, और उस स्टोर। फिर जब आप इसे पुनः प्राप्त करते हैं, तो आप '\ 0' द्वारा विभाजित कर सकते हैं। बेशक इस सामान के बारे में जाने के अन्य तरीके हैं, लेकिन वे आपके विशिष्ट डेटाबेस विक्रेता पर निर्भर हैं।

एक उदाहरण के रूप में, आप JSON को पोस्टग्रेज डेटाबेस में संग्रहीत कर सकते हैं। यदि आपकी सूची पाठ है, और आप बिना अधिक परेशानी के सूची चाहते हैं, तो यह एक उचित समझौता है।

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

यदि आप इस तरह का काम करना चाहते हैं, तो आमतौर पर सरणी-या-समान प्रकार उपलब्ध हैं। उदाहरण के लिए, एक प्रकार के रूप में सरणी प्रदान करता है, और अगर आप चाहते हैं कि आप पाठ की एक सरणी स्टोर कर सकते हैं , और JSON का उपयोग करके MySql और MS SQL के लिए समान चालें हैं , और IBM के DB2 एक सरणी प्रकार भी प्रदान करते हैं (उनके रूप में) स्वयं सहायक प्रलेखन)। अगर इसकी आवश्यकता नहीं होती तो यह इतना सामान्य नहीं होता।

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

Answer 5

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

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

Comments

भविष्य के परिवर्तनों की आशंका के लिए +1 - हमेशा अपने डेटा मॉडल को एक्स्टेंसिबल होने के लिए डिज़ाइन करें।

— कुंडली

Answer 6

मैं बस इसे CSV के रूप में संग्रहीत करूंगा, यदि यह सरल मान है तो इसकी आपको सभी आवश्यकताएं होनी चाहिए (XML बहुत ही क्रियात्मक है और इसमें से / के लिए क्रमबद्ध करना संभवत: ओवरकिल होगा लेकिन यह भी एक विकल्प होगा)।

यहाँ LINQ के साथ CSV को कैसे निकाला जाए, इसका एक अच्छा उत्तर है ।

Comments

मैं हालांकि उस बारे में। इसका अब भी मतलब है कि मुझे सीरियल करना होगा और डिसेर्बलाइज करना होगा ... लेकिन मुझे संदेह है कि यह उल्लेखनीय है। मैं कुछ नहीं था इच्छा माफ़ मैं क्या करना चाहते हैं जिस तरह से है, लेकिन मुझे लगता है वहाँ नहीं है।

— 14:27 पर JnBrymn

capnproto.org एक तरह से करने के लिए इसी तरह त्वरित serialize और deserialize करने की जरूरत नहीं, मामले capnproto में (CSV या XML की तुलना में) पसंद का अपनी भाषा में समर्थित नहीं है msgpack.org/index.html

— VoronoiPotato

Answer 7

यदि आपको सूची पर क्वेरी करने की आवश्यकता है, तो इसे एक तालिका में संग्रहीत करें।

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

Answer 8

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

यहाँ यह 'पारंपरिक' DB डिजाइन है:

List(ListID, ListName) 
Item(ItemID,ItemName) 
List_Item(ListID, ItemID, SortOrder)

यहाँ यह डी-सामान्यीकृत तालिका है:

Lists(ListID, ListContent)

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

Answer 9

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

Answer 10

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

Answer 11

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

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

यहां मेरा जवाब है: मैंने सूची के प्रत्येक आइटम की निश्चित लंबाई का उपयोग करके, पोस्टग्रेएसक्यूएल में एक क्षेत्र में सफलतापूर्वक एक सूची लागू की है। मान लें कि प्रत्येक आइटम ARGB हेक्स मूल्य के रूप में एक रंग है, इसका मतलब 8 char है। तो आप प्रत्येक आइटम की लंबाई से गुणा करके अधिकतम 10 आइटमों की अपनी सरणी बना सकते हैं:

ALTER product ADD color varchar(80)

यदि आपकी सूची आइटम्स की लंबाई अलग-अलग है तो आप हमेशा गद्दी को 0 से भर सकते हैं

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

कारण क्यों: 1 / बहुत सुविधाजनक: i, n, (i +1) * n के विकल्प पर आइटम i को पुनः प्राप्त करें। 2 / क्रॉस टेबल क्वेरी का कोई ओवरहेड नहीं। सर्वर साइड पर 3 / अधिक कुशल और लागत-बचत। सूची एक मिनी ब्लॉब की तरह है जिसे क्लाइंट को विभाजित करना होगा।

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

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

मैं यह नहीं बताता कि यह समाधान एक सफलता है, और न ही यह पठनीयता और डेटाबेस लचीलेपन की अवधि में आदर्श है, लेकिन जब यह विलंबता की स्थिति में आता है, तो यह निश्चित रूप से आपको बढ़त दिला सकता है।

Comments

लेकिन यह एक बहुत ही विशिष्ट मामला है: निश्चित लंबाई की वस्तुओं की एक निश्चित संख्या। फिर भी, यह मानक एसक्यूएल की तुलना में "कम से कम रंग x वाले सभी उत्पादों" की तरह एक सरल खोज करता है।

— गर्ट अर्नोल्ड

जैसा कि मैंने कई बार कहा, मैं इसे रंग के लिए उपयोग नहीं करता हूं, जिस क्षेत्र का उपयोग करता हूं उसे अनुक्रमित नहीं किया जाना चाहिए और न ही एक शर्त के रूप में उपयोग किया जाना चाहिए, और फिर भी यह एक महत्वपूर्ण है

— एंटोनिन गेवल

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

— गर्ट अर्नोल्ड

Answer 12

कई SQL डेटाबेस एक तालिका को एक घटक के रूप में एक सबटेबल में शामिल करने की अनुमति देते हैं। सामान्य विधि यह है कि स्तंभों में से किसी एक के डोमेन को तालिका बनाने की अनुमति दी जाए। यह कुछ सम्मेलनों का उपयोग करने के अलावा CSV का उपयोग करके DBMS से अज्ञात तरीके से सबस्ट्रक्ट को एनकोड करने के लिए है।

जब एड कोड 1969-1970 में रिलेशनल मॉडल विकसित कर रहा था, तो उसने विशेष रूप से एक सामान्य रूप को परिभाषित किया जो इस तरह के तालिकाओं के घोंसले को खत्म कर देगा। सामान्य रूप को बाद में फर्स्ट नॉर्मल फॉर्म कहा जाता था। फिर उन्होंने यह दिखाया कि प्रत्येक डेटाबेस के लिए, पहले सामान्य रूप में एक डेटाबेस होता है जो समान जानकारी को व्यक्त करता है।

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

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

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

Answer 13

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

डेटाबेस:

 _____________________
|  word  | letters    |
|   me   | '[m, e]'   |
|  you   |'[y, o, u]' |  note that the letters column is of type 'TEXT'
|  for   |'[f, o, r]' |
|___in___|_'[i, n]'___|

और सूची संकलक फ़ंक्शन (अजगर में लिखा गया है, लेकिन इसे आसानी से अधिकांश अन्य प्रोग्रामिंग भाषाओं में अनुवाद किया जाना चाहिए)। पाठ वर्ग तालिका से लोड पाठ का प्रतिनिधित्व करता है। स्ट्रिंग युक्त सूची से स्ट्रिंग की सूची लौटाता है। यदि आप चाहते हैं कि यह तार के बजाय ints को लौटाए, तो 'int' के बराबर मोड बनाएं। इसी तरह 'स्ट्रिंग', 'बूल', या 'फ्लोट' के साथ।

def string_to_list(string, mode):
    items = []
    item = ""
    itemExpected = True
    for char in string[1:]:
        if itemExpected and char not in [']', ',', '[']:
            item += char
        elif char in [',', '[', ']']:
            itemExpected = True
            items.append(item)
            item = ""
    newItems = []
    if mode == "int":
        for i in items:
            newItems.append(int(i))

    elif mode == "float":
        for i in items:
            newItems.append(float(i))

    elif mode == "boolean":
        for i in items:
            if i in ["true", "True"]:
                newItems.append(True)
            elif i in ["false", "False"]:
                newItems.append(False)
            else:
                newItems.append(None)
    elif mode == "string":
        return items
    else:
        raise Exception("the 'mode'/second parameter of string_to_list() must be one of: 'int', 'string', 'bool', or 'float'")
    return newItems

यहाँ भी एक सूची-से-स्ट्रिंग फ़ंक्शन है यदि आपको इसकी आवश्यकता है।

def list_to_string(lst):
    string = "["
    for i in lst:
        string += str(i) + ","
    if string[-1] == ',':
        string = string[:-1] + "]"
    else:
        string += "]"
    return string