आप डेटा के छोटे सेट कैसे संभालते हैं?

Question

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

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

तो आप अकसर बदले गए डेटा के छोटे सेट कैसे प्रबंधित करते हैं? क्या आपने डेटाबेस तालिका या टेक्स्ट फ़ाइल का उपयोग करने के लिए मानदंड निर्धारित किए हैं या ..?

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

संपादित करें: संदर्भ के लिए:

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

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

Answer 1

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

Answer 2

इसे डेटाबेस में रखें। यदि यह बार-बार बदलता है, तो इसे अपने मध्यम स्तर पर कैश करें।

Answer 3

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

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

Answer 4

निश्चित रूप से यह आकार के बावजूद, डेटा के सेट का उपभोग करने के लिए विकसित सॉफ्टवेयर टूल के उपयोगकर्ता पर निर्भर करता है?

यह हो सकता है कि वे एक्सेल को जानते हों, इसलिए आपके टूल को उनके द्वारा बनाई गई .csv फ़ाइल को पार्स करना होगा।

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

Answer 5

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

Answer 6

ऐसे मामलों में जहां प्रोग्राम डेटाबेस का उपयोग करता है, मैं वहां सबकुछ स्टोर करूंगा: बैकअप के लिए आसान और डेटा को चारों ओर ले जाना।

डेटाबेस एक्सेस के बिना छोटे प्रोग्रामों के लिए मैं अपने डेटा को .net सेटिंग्स में संग्रहीत करता हूं, जो कि एक XML फ़ाइल में संग्रहीत हैं - बेशक यह सी # की एक विशेषता है, इसलिए यह आपके लिए लागू नहीं हो सकता है।

वैसे भी, मैं एक ही स्थान पर सभी डेटा स्टोर करना सुनिश्चित करता हूं। आमतौर पर एक डेटाबेस।

Answer 7

मैं मुख्य तालिका में डेटाबेस के लिए यह जोड़ना होगा:

1. बैकअप और वसूली (आप इस पाठ फ़ाइल ठीक करने के लिए, सही करना चाहते हैं?)
2. Adhoc क्वेरी (के बाद से आप यह कर सकते हो जाएगा एक एसक्यूएल उपकरण और अन्य डेटाबेस डेटा में शामिल हों)
3. यदि डेटाबेस कॉलम खाली है तो इसके लिए स्टोर आवश्यकताएं कम होनी चाहिए (ओरेकल में तालिका के अंत में यह एक पूर्ण कॉलम नहीं है)
4. यह होगा यदि आप एकाधिक एप्लिकेशन सर्वर रखना चाहते हैं तो आसान हो क्योंकि आपको टी की आवश्यकता नहीं होगी ओ के आसपास
5. एक छोटा बच्चा तालिका में यह लाना कुछ अतिरिक्त कॉन्फ़िग फ़ाइल की कई प्रतियां रखने के केवल किसी भी वास्तविक लाभ

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

Answer 8

क्या आपने sqlite पर विचार किया है? यह फ़ाइल-आधारित है, जो आपकी भावना को संबोधित करता है कि "बस एक फ़ाइल हो सकती है" (शून्य कॉन्फ़िगरेशन), लेकिन यह एक बिल्कुल अच्छा डेटाबेस और स्केल उल्लेखनीय रूप से अच्छी तरह से है। यह कई एपीआई का समर्थन करता है और इसे प्रशासित करने के लिए numerous front ends हैं।