डीबी का उपयोग करने के विपरीत एक हार्ड-कोड वास्तविक डेटा मान कोड में कब होता है?

Question

मेरे लिए लंबे समय से एक प्रश्न है: जब मैं डेटाबेस तालिका में डेटा (वास्तविक मान) संग्रहीत करता हूं, और मैं उन्हें कोड में सही कब संग्रहीत करता हूं?

अनकहा आम सहमति आमतौर पर इस प्रकार है (*):

यदि यह एक एकल चर या एक सरल संरचना है, या कुछ मानों की एक सरणी है, तो कोड में डेटा डालें।

[* सर्वसम्मति से टिप्पणियों और उत्तरों में बहस की गई है, लेकिन मूल रूप से मैं इस सवाल को उछालना शुरू करने के लिए किसी तरह का आधार चाहता था, इसलिए इसे चुनौती देने और उस पर सुधार करने के लिए स्वतंत्र महसूस करें ]

उदाहरण:

$number = 44;
$colors = array("blue", "yellow", ... "mauve");

यदि इसमें एक ही प्रकार के डेटा की सैकड़ों + पंक्तियाँ हैं, तो डेटाबेस का उपयोग करें।

लेकिन वहाँ एक ग्रे क्षेत्र लगता है; उन मामलों के बारे में जो इतने स्पष्ट नहीं हैं? निर्णय लेने के लिए किन विचारों और कारकों पर ध्यान देने की आवश्यकता है?

उदाहरण:
मान लें कि आपकी कंपनी 10-15 विभिन्न प्रकार के मोटर्स फ्रेम का उपयोग करती है जिसे "412T" के रूप में दर्शाया जा सकता है। आपके पास उनमें से लगभग 30 हैं और वे शायद ही कभी बदलते हैं। आप या तो उन लोगों के लिए एक डीबी तालिका बना सकते हैं या उन्हें डेटाबेस में हार्ड-कोड कर सकते हैं। इस मामले में, मोटर्स स्थिर हैं, भौतिक चीजें जो अक्सर बदलने की संभावना नहीं हैं।

कोड विषयों में उन्हें स्रोत नियंत्रण में रखते हुए, जहां एक डेटाबेस में, DB परिवर्तनों को आमतौर पर ट्रैक नहीं किया जाता है। लेकिन उन्हें डेटाबेस में रखने से डेटा से कोड अलग (अलग) हो जाता है।

एक और (वास्तविक) उदाहरण मैं उपयोग कर सकता हूं यह मेरा सवाल है: /programming/26169751/how-to-best-get-the-data-out-of-a-lookup-table (वर्तमान में 48) विकल्प डेटा की पंक्तियाँ)।

Comments

अनकही आम सहमति आमतौर पर ऐसी नहीं रही है: यदि यह एकल चर या सरल संरचना है, या कुछ मानों की एक सरणी है, तो कोड में डेटा को सही तरीके से रखें।

— पीटर बी

एक मध्य तरीका है: डेटा एक डेटाबेस में संग्रहीत किया जाता है। फिर इसे स्रोत कोड (जैसे, एक global_constants.hफ़ाइल में) लिखने के लिए निकाला जाता है ।

— मौविसील

@mouviciel लेकिन क्या डेटा बनता है ... आपको डेटाबेस तक पहुंचने के लिए कुछ डेटा की आवश्यकता होती है, इसलिए आप सभी डेटा को वहां संग्रहीत नहीं कर सकते।

— jwenting

Answer 1

मुझे नहीं लगता कि ये दोनों कथन वास्तव में कब कोड डेटा के बारे में आम सहमति का प्रतिनिधित्व करते हैं:

यदि यह एक एकल चर या एक सरल संरचना है, या कुछ मानों की एक सरणी है, तो कोड में डेटा डालें

यदि इसमें एक ही प्रकार के डेटा की सैकड़ों + पंक्तियाँ हैं, तो डेटाबेस का उपयोग करें

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

इसके बजाय मैं सबसे पहले पूछने पर ध्यान दूंगा:

• डेटा कितनी बार बदलता है?

• इसे बदलने की आवश्यकता किसे हो सकती है?

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

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

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

लेकिन उस स्थिति में भी, सहयोग करने की आवश्यकता सामने आ सकती है, और यह मुश्किल हो सकता है यदि कोई कस्टम अनुप्रयोग किसी सम्मेलन का पालन नहीं करता है जो प्रोग्रामर आमतौर पर करते हैं।

Comments

अक्सर पूछे जाने वाले प्रश्न के समान, एक और प्रश्न है, "कितनी जल्दी इसे बदलने की आवश्यकता है?" गेटिंग फैक्टर यह हो सकता है कि आपके उपयोगकर्ता आधार पर तैनात होने में कितना समय लगे। केंद्रीकृत सर्वर सॉफ्टवेयर के लिए, उत्तर मिनट हो सकता है, लेकिन क्षेत्र में मोबाइल एप्लिकेशन के लिए, इसमें सप्ताह लग सकते हैं।

— २२:०४ पर क्यूरियस रैबिट

पर्ल उदाहरण में, मैं इसे an array with a few valuesमूलभूत डेटा प्रकार की 377-ish पंक्तियों के रूप में रखूँगा। शायद कुछ के लिए "कुछ" से अधिक है, लेकिन यह अभी भी बहुत छोटा है। मेरे पास अभी तक समान रूप से कम फ्लैट संरचनाएं हार्डकोडेड हैं। यदि यह एक हजार + पंक्तियाँ होतीं तो शायद मैं इसे इस तरह हार्डकोड करने के लिए अधिक अनिच्छुक हो जाता।

— डेनिस

Answer 2

मैं तीसरे विकल्प के साथ जाऊँगा: एक विन्यास फाइल!

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

motorFramesString=412T, 413T, ...

वसंत विन्यास में:

<bean="motorFrameManager" class="myCompany.MotorFrameManager" >
    <property name="motorFrames" value="${motorFrames}"/>
</bean>

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

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

---

एक और अधिक जटिल उदाहरण जैसे कि आप जो लिंक करते हैं वह भी किया जा सकता है, गुणों के साथ या बाहर।

उत्पादों में।

productA.name=Product A 123
productA.hasMotor=true
productA.numFeet=1
productA.hasOutlet=true
productA.needsManual=true

productB.name=Product B 456
productB.hasMotor=false
productB.numFeet=1
productB.hasOutlet=true
productB.needsManual=true

आपकी स्प्रिंग कॉन्फ़िगरेशन फ़ाइल में:

<bean name="productA" class="com.mycompany.Product">
   <property name="name" value="${productA.name}"/>
   <property name="hasMotor" value="${productA.hasMotor}"/>
   <!-- rest omitted for brevity -->
</bean>
<bean name="productB" class="com.mycompany.Product">
   <property name="name" value="${productB.name}"/>
   <property name="hasMotor" value="${productB.hasMotor}"/>
   <!-- rest omitted for brevity -->
</bean>
<!-- configure as many beans as needed -->
<bean="motorFrameManager" class="myCompany.MotorFrameManager" >
    <property name="motorFrames"> <!-- assumes that MotorFrameManager has a property motorFrames which is a List<Product> -->
        <list>
            <ref bean="productA"/>
            <ref bean="productB"/>
        </list>
    </property>
</bean>

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

Comments

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

— डेनिस

@ डेनिस: एक अधिक जटिल उदाहरण जोड़ा गया।

— फ्रस्ट्रेटेडविथफॉर्म्सडिजाइनर

एक config फाइल db का सिर्फ एक रूप है।

— डगएम

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

— mcottle

@gbjbaanb: अधिकांश अनुप्रयोगों के लिए RDBMS WAAAAAY ओवरकिल है, यहां तक ​​कि अन्यथा व्यापक प्रणालियों के लिए भी। यह उल्लेख नहीं करने के लिए कि वे धीमे हैं और बनाए रखने और एकीकृत करने के लिए उचित मात्रा में प्रयास की आवश्यकता है। "आईआईएन" फाइलें किसी भी प्रकार की सुरक्षा प्रदान नहीं करती हैं, आपको स्वयं पार्सर लिखना होगा और आपको अपनी स्वयं की टाइपिंग जांच लिखनी होगी। XML विन्यास फाइल, कम से कम .Net में, अपने पसंदीदा विकल्पों में से किसी एक के द्वारा अनिवार्य रूप से मुफ्त में दिए गए सभी लाभ प्राप्त करें। तो आपका दावा है कि XML कॉन्फिग फाइल हमेशा एक बदतर विकल्प है और अधिक गलत नहीं हो सकता है।

— डंक

Answer 3

मुझे लगता है कि प्रश्न का आधार बिलकुल सही नहीं है। विभाजन कारक रिकॉर्ड की मात्रा नहीं है जिसे बदलने की आवश्यकता है, बल्कि परिवर्तनों की आवृत्ति के साथ-साथ उन्हें कौन बदलता है।

आवृत्ति

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

कौन

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

सामान्य थ्रेड

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

परिक्षण

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

Answer 4

यह न तो परिवर्तनों की आवृत्ति है और न ही डेटा की मात्रा जो यह तय करती है कि डेटा कहाँ संग्रहीत किया जाए।

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

बेशक, कॉन्फ़िगर फाइलें, चित्र, ध्वनियां, आदि आमतौर पर फाइल सिस्टम पर बेहतर संग्रहित होती हैं।

Comments

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

— डगएम

मैं 8 साल के लिए ओरेकल डेवलपर था, लेकिन मुझे अभी भी ऐसे एप्लिकेशन पसंद नहीं हैं जिनमें अंतर्निहित डेटाबेस के साथ इस तरह के तंग युग्मन हैं।

— winkbrace

Answer 5

यदि कोई मामूली मौका है, तो आपको कभी भी एक फोन कॉल आएगा जिसके परिणामस्वरूप आपको एक एप्लिकेशन का पुनर्निर्माण करना होगा क्योंकि कुछ हार्ड-कोडित बदल गया है, तो इसे हार्ड-कोड न करें। बहुत कम से कम इसे एक config फाइल या db टेबल में रखें। आपको इसे आवश्यक रूप से बनाए रखने के लिए कोई यूआई प्रदान करने की आवश्यकता नहीं है, लेकिन एक कॉन्फ़िगर फ़ाइल को डायल करना और बदलना या एक तालिका पर SQL UPDATE चलाना निश्चित रूप से पूरे शूटिंग मैच के पुनर्निर्माण के लिए बेहतर है।

Answer 6

भेद वास्तव में एक ग्रे क्षेत्र है, लेकिन इस तरह के मुद्दों के लिए मेरा दृष्टिकोण है: क्या डेटा उत्पादन में बदलता है "? उत्पादन वातावरण में तैनाती के बाद जो भी बदलाव होता है, उसे डेटाबेस में जाना चाहिए, यहां तक ​​कि उन चीजों के लिए भी जो शायद ही कभी बदल सकते हैं।

तो आप जो सवाल पूछ रहे हैं वह यह नहीं है कि "यह कितनी बार बदलेगा?", लेकिन "क्या यह बदल सकता है?"। यदि किसी गुण का मान उत्पादन परिवेश पर समान कोड पुनरावृत्ति (कोड में किसी और चीज़ को स्पर्श किए बिना) में भिन्न हो सकता है, तो यह डेटाबेस में जाता है।

Answer 7

आप जो भी याद कर रहे हैं वह "प्रोग्राम कंट्रोल" है टाइप जानकारी में अधिकतम बफर आकार, एक क्रम में आइटमों की संख्या, एक स्क्रीन के लिए अधिकतम पृष्ठ आकार हमेशा बेहतर होता है या तो प्रोग्राम में या कॉन्फ़िगरेशन फ़ाइल में हार्ड कोडित होता है।

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

दूसरी समस्या यह है कि स्रोत नियंत्रण / परिवर्तन प्रबंधन / स्वचालित निर्माण प्रणालियों के माध्यम से डेटाबेस प्रविष्टियां प्राप्त करने का कोई आसान तरीका नहीं है जिसका आपको उपयोग करना चाहिए।

Answer 8

एक बात जो आपको डेटाबेस में कभी नहीं रखनी चाहिए वह है डेटाबेस तक पहुँचने के लिए आवश्यक विवरण।
अगर आपको डेटाबेस से एक्सेस करने की आवश्यकता है, तो आप सभी को एक ही डेटाबेस के लिए कनेक्ट स्ट्रिंग्स, उपयोगकर्ता नाम और पासवर्ड प्राप्त करने के लिए एक कैच -22 का एक सा है।

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

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

इसके अलावा, ऐसी चीजें हैं जो कभी नहीं बदलती हैं। प्राकृतिक स्थिरांक जैसी चीजें (जी, पी, ई, आप इसे नाम देते हैं), कुछ चीजें जैसे कुछ नियमित अभिव्यक्तियाँ, जैसे ईमेल सत्यापन।