स्थैतिक डेटा को डेटाबेस में संग्रहीत किया जाना चाहिए या कहीं और?

20

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

मेरे पास निम्नलिखित विकल्प हैं:

Enums / वस्तुओं का एक सेट
एक XML फ़ाइल
एम्बेडेड SQLite डेटाबेस

इस विशेष मामले में मुझे लगता है कि enums विकल्प कम से कम काम है, लेकिन मुझे उस तरह के कोड में एम्बेडेड डेटा से एक गंध मिलती है।

XML फ़ाइल मुझे सबसे अधिक समझ में आती है, लेकिन इसे पार्स करने से एक संसाधन हिट होगा जो एक बर्बादी की तरह लगता है क्योंकि यह कभी नहीं बदलेगा।

डेटाबेस को कम से कम एक प्रदर्शन हिट प्रदान करना चाहिए, लेकिन ऐसा लगता है जैसे स्थैतिक डेटा के लिए ओवरकिल।

यहाँ सही डिज़ाइन पथ कौन सा है?

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

design

— CurlyPaul
स्रोत

2

इस दृष्टिकोण में से प्रत्येक के बीच प्रदर्शन-वार समय का संदर्भ क्या है? क्या आपने पहले उनका परीक्षण / बेंचमार्क किया था?

— महदी

1

"शायद ही कभी बदलते हैं" - क्या इसे रनटाइम में बदलने की आवश्यकता होगी? एप्लिकेशन स्टार्टअप पर? या इसके लिए एक नया निर्माण स्वीकार्य है?

यह रनटाइम के दौरान या स्टार्ट अप में कभी नहीं बदलेगा। एक नया निर्माण स्वीकार्य होगा

— कर्लीपॉल

मुझे नहीं लगता कि यहां एक स्पष्ट 'होना चाहिए'। आपने डेटा की मात्रा, इसकी प्रकृति और इसका उपयोग कैसे किया जाता है, दोनों के बारे में बहुत कम जानकारी प्रदान की है। मैंने उपरोक्त सभी अतीत में किया है ... आप किस मार्ग पर जाते हैं यह वास्तव में निर्भर करता है ।

— ग्रैंडमास्टरबी

इनम / ऑब्जेक्ट्स के रूप में एम्बेडेड डेटा होना गलत नहीं है, यह बहुत सरल, सबसे साफ और सबसे सही हो सकता है। यह सब इस बात पर निर्भर करता है कि डेटा भविष्य में क्या बदल सकता है।

— जैक्सबी

18

मैं इसके लिए किसी ऑब्जेक्ट का उपयोग करूंगा।

आपने कहा कि डेटा कभी नहीं बदलेगा, इसलिए आप इसे एप्लिकेशन में आसानी से संग्रहीत कर सकते हैं। डेटाबेस ओवरकिल होगा और आकार बढ़ाएगा।
XML फ़ाइल थोड़े ओवरकिल भी होगी और आकार में भी वृद्धि करेगी।

तो मेरी राय में सबसे अच्छा विकल्प एक एनम या ऑब्जेक्ट होगा।

— Knerd
स्रोत

2

यही कारण है कि मैं ईमानदार होने की ओर रुझान कर रहा हूं, केवल एक चीज जो मुझे पसंद नहीं है वह कोड के साथ डेटा मिश्रण करना है। कभी-कभी मुझे यह स्वीकार करना पड़ता है कि सबसे अच्छा रास्ता हमेशा मेरे OCD के साथ फिट नहीं होता है

— CurlyPaul

एक एनम बुरा नहीं है;) आपके पास किस तरह का डेटा है?

— किन्र्ड

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

— CurlyPaul

11

क्या यह कभी नहीं बदलेगा, या यह बदलेगा? इससे पहले कि आप एक अच्छी प्रतिक्रिया पाने से पहले आपको वास्तव में जवाब देना होगा।

स्थैतिक डेटा जो कभी नहीं बदलते (जैसे सप्ताह के दिनों के नाम) कोड में जाने के लिए अच्छे हैं;

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

वह डेटा जो परिवर्तित नहीं होता है, लेकिन समय-समय पर रिफ्रेश के बीच समय की देरी हो सकती है (शायद समय-समय पर रिफ्रेशमेंट में सबसे अच्छा है), जैसे कि स्थानीय कॉन्फिगरेशन स्टोर (साइक्लाइट या xml) में कोई वास्तविक अंतर नहीं होता है।

भंडारण थोड़ा चिंता का विषय है - अगर यह कभी नहीं या शायद ही कभी बदलता है, तो आप इसे प्रोग्राम प्रारंभ में पढ़ सकते हैं और इसे प्रोग्राम डेटा के रूप में कैश कर सकते हैं। यदि, अप्रत्याशित घटना में इसे कभी भी बदलने की आवश्यकता होती है, तो ऐप का पुनः आरंभ इतना बड़ा सौदा नहीं है।

— gbjbaanb
स्रोत

मैंने इस मामले में कितनी बार 'कभी नहीं' होने के बारे में कुछ जानकारी जोड़ी

— CurlyPaul

@CurlyPaul ने उन्हें कोड में बाँध दिया, यदि वे बदलते हैं तो आपको शायद कोड को भी अपडेट करना होगा। अगर यह आपके कोडिंग / परीक्षण को आसान बनाता है तो केवल उन्हें एक sqlite / xml db में डालें।

— gbjbaanb

"स्टेटिक डेटा जो कभी नहीं बदलता है (जैसे सप्ताह के दिनों के नाम) कोड में जाने के लिए अच्छा है" और फिर भी आप गलत हो सकते हैं: तब तक प्रतीक्षा करें जब तक आपका ऐप अंतर्राष्ट्रीय नहीं हो जाता। सप्ताह के नाम बिल्कुल स्थिर नहीं हैं।

— पीटर बी

@ पीटर यह मेरे सिर के ऊपर से एक उदाहरण मात्र था। क्या 'सप्ताह में दिन की संख्या' आपके लिए एक कम नाइट-पिकेबल उदाहरण होगा?

— gbjbaanb

@gbjbaanb जब तक हम दूसरे ग्रहों का उपनिवेश बनाना शुरू नहीं करते हैं, तब तक प्रतीक्षा करें। फिर आप क्या करने जा रहे हैं? / एस

— मिनीरग्नोक

5

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

— jwenting
स्रोत

मैंने इस बारे में कुछ जानकारी जोड़ी कि इस मामले में 'कभी नहीं' कितनी बार होने वाली है। आपके इनपुट के लिए धन्यवाद

— CurlyPaul

आइए लिंग M (ale) और F (emale) को स्टोर करने के लिए एक टेबल "जेंडर" बनाएं, क्या वे बदलते हैं?

— मार्टिन फेफर

4

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

सवाल यह है कि जब यह बदलता है, तो इसे किसे बदलना चाहिए:

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

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

आप अपने सभी उपयोगकर्ताओं को उस भाग्य से बचने के लिए कॉन्फ़िगर फ़ाइलों या अस्पष्ट डेटाबेस तालिकाओं में खुदाई करने के लिए नहीं चाहते हैं ...

— soru
स्रोत

पागल तानाशाहों, पागल परियोजना प्रबंधकों, पागल ग्राहकों ... pff।

— महदी

यह सही जवाब है!

— जैक्सबी

2

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

उदाहरण:

टंकण त्रुटि / गलत वर्तनी।
आकस्मिक चूक।
डेटा को किसी अन्य भाषा में पेश करें।
उपयोगकर्ता को अपने स्वयं के परिवर्तन करने का एक तरीका प्रदान करें।

किसी अन्य प्रकार के डेटा संरचना परिवर्तन को संभवतः ऐप को अपडेट करने की आवश्यकता होगी, ताकि कोई लाभ न हो।

— JeffO
स्रोत

1

मैं मूल रूप से इस जवाब लिखा stackoverflow पर इस सवाल है, लेकिन मुझे लगता है कि एक ही जवाब इस प्रश्न के लिए भी लागू होता है।

मैथियास वेराज़ का एक लेख है जो आपकी समस्या के बारे में यहाँ बताता है । वह यूआई की सेवा करने वाली अवधारणाओं से मॉडल में मूल्य वस्तुओं को अलग करने के बारे में बात करता है।

लेख से यह पूछते हुए कि क्या देशों को संस्थाओं या मूल्य वस्तु के रूप में मॉडल करना है:

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

उन्होंने एक नई अवधारणा पेश करने के लिए एक अलग दृष्टिकोण का सुझाव दिया AvailableCountry:

ये उपलब्ध देश एक डेटाबेस में इकाइयाँ, एक JSON में रिकॉर्ड, या यहां तक कि आपके कोड में केवल एक हार्डकोड सूची हो सकती है। (यह इस बात पर निर्भर करता है कि व्यवसाय यूआई के माध्यम से उनके लिए आसान पहुंच चाहता है।)

<?php

final class Country
{
    private $countryCode;

    public function __construct($countryCode)
    {
        $this->countryCode = $countryCode;
    }

    public function __toString()
    {
        return $this->countryCode;
    }
}

final class AvailableCountry
{
    private $country;
    private $name;

    public function __construct(Country $country, $name)
    {
        $this->country = $country;
        $this->name = $name;
    }

    /** @return Country */
    public function getCountry()
    {
        return $this->country;
    }

    public function getName()
    {
        return $this->name;
    }

}

final class AvailableCountryRepository
{
    /** @return AvailableCountry[] */
    public function findAll()
    {
        return [
            'BE' => new AvailableCountry(new Country('BE'), 'Belgium'),
            'FR' => new AvailableCountry(new Country('FR'), 'France'),
            //...
        ];
    }

    /** @return AvailableCountry */
    public function findByCountry(Country $country)
    {
        return $this->findAll()[(string) $country];
    }
}

तो ऐसा लगता है कि एक 3 समाधान है जो मूल्य वस्तुओं और संस्थाओं के रूप में तालिकाओं को मॉडल करने के लिए है।

BTW सुनिश्चित करें कि आप लेख के बारे में कुछ गंभीर चर्चाओं के लिए टिप्पणी अनुभाग देखें।

— Songo
स्रोत

-1

विचार करने के लिए बातें:

डेटा कितना स्थिर है? यदि वह कभी नहीं बदलेगा, तो उसे वस्तु में रहना चाहिए। डेटा को बदलने के लिए, आपको पुन: संकलित और पुन: संकलित करना पड़ सकता है। क्या आप मामूली बदलाव के लिए पुनर्खरीद करने से खुश हैं?
यदि यह एक वेब अनुप्रयोग है और आपके पास web.config के भाग के रूप में है, तो क्या आप उस डेटा में परिवर्तन करने पर अनुप्रयोग पुनः आरंभ होने से खुश हैं?
यदि आप इसे डेटाबेस में रखते हैं, तो आप इसे हमेशा क्लाइंट साइड (डेस्कटॉप एप्लिकेशन) या सर्वर साइड (सेवा या वेबसाइट) पर कैश कर सकते हैं। डेटाबेस एक अच्छा समाधान IMO हो सकता है।

— CodeART
स्रोत

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

— gnat