কোনও হার্ড-কোড প্রকৃত ডেটা যখন ডিবি ব্যবহারের বিপরীতে কোডের সাথে মান দেয়?

17

আমার জন্য একটি দীর্ঘস্থায়ী প্রশ্ন ছিল: আমি কখন ডেটাবেস টেবিলের মধ্যে ডেটা (প্রকৃত মান) সংরক্ষণ করি এবং আমি কখন সেগুলি কোডে সংরক্ষণ করি?

অবিসংবাদিত sensক্যমত সাধারণত (যেমন):

যদি এটি একটি একক পরিবর্তনশীল বা একটি সাধারণ কাঠামো, বা কয়েকটি মানের একটি অ্যারে থাকে তবে ডান কোডে রেখে দিন।

[* commentsক্যমত্য মন্তব্য এবং উত্তরে বিতর্কিত হয়েছে, তবে মূলত আমি প্রশ্নটি শুরু করার জন্য একধরণের ভিত্তি চেয়েছিলাম, তাই নির্দ্বিধায় চ্যালেঞ্জ জানাতে এবং এটিকে উন্নত করতে ]]

উদাহরণ:

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

যদি এটির একই ধরণের ডেটা কয়েক শত + থাকে তবে একটি ডাটাবেস ব্যবহার করুন।

তবে ধূসর অঞ্চল বলে মনে হচ্ছে; এতটা স্পষ্ট নয় এমন কেস সম্পর্কে কী বলা যায়? সিদ্ধান্ত নেওয়ার জন্য কার বিবেচ্য বিষয় ও কারণগুলির প্রতি মনোযোগ দেওয়া দরকার?

উদাহরণ:
বলুন আপনার সংস্থা 10-15 বিভিন্ন ধরণের মোটর ফ্রেম ব্যবহার করে যা "412T" হিসাবে উপস্থাপিত হতে পারে। আপনার প্রায় 30 টি রয়েছে এবং সেগুলি খুব কমই পরিবর্তিত হয়। আপনি হয় তাদের জন্য একটি ডিবি টেবিল তৈরি করতে পারেন বা একটি ডাটাবেসে হার্ড-কোড করতে পারেন। এই ক্ষেত্রে, মোটরগুলি স্থির, শারীরিক জিনিস যা প্রায়শই পরিবর্তিত হওয়ার সম্ভাবনা থাকে না।

কোডগুলিতে তাদের সোর্স নিয়ন্ত্রণে রাখা, যেখানে কোনও ডাটাবেজে ডিবি পরিবর্তনগুলি সাধারণত ট্র্যাক করা হয় না। তবে এগুলি একটি ডাটাবেসে রাখা তথ্য থেকে কোডকে মুক্ত করে (পৃথক করে)।

আরেকটি (প্রকৃত) উদাহরণ আমি ব্যবহার করতে পারি তা হ'ল আমার এই প্রশ্ন: /programming/26169751/how-to-best-get-the-data-out-of-a-lookup-table (বর্তমানে 48 বিকল্প ডেটা সারি)।

database source-code separation-of-concerns

— ডেনিস
সূত্র

3

অবিচ্ছিন্ন conকমত্যটি সাধারণত তেমনটি হয় নি: যদি এটি একটি একক পরিবর্তনশীল বা একটি সাধারণ কাঠামো বা কয়েকটি মানের অ্যারে হয় তবে ডানাকে কোডের মধ্যে রাখুন।

— পিটার বি

মধ্যম উপায় রয়েছে: ডেটাবেস একটি ডেটাবেজে সংরক্ষণ করা হয়। তারপরে এটি উত্স কোড লিখতে নিষ্কাশন করা হয় (উদাহরণস্বরূপ, কোনও global_constants.hফাইলে)।

— mouviciel

@ মউভিচিয়েল তবে কী ডেটা গঠন করে ... ডাটাবেস অ্যাক্সেস করার জন্য আপনার কিছু ডেটা দরকার, যাতে আপনি সেখানে সমস্ত ডেটা সংরক্ষণ করতে পারবেন না।

— ই

33

আমি মনে করি না যে এই দুটি বিবৃতিটি সত্যিকারের হার্ড কোড ডেটা সম্পর্কে একটি representক্যমতের প্রতিনিধিত্ব করে:

যদি এটি একটি একক পরিবর্তনশীল বা একটি সাধারণ কাঠামো, বা কয়েকটি মানের একটি অ্যারে থাকে তবে ডান কোডে রেখে দিন

যদি এটির একই ধরণের ডেটা কয়েক শত + থাকে তবে একটি ডাটাবেস ব্যবহার করুন

সাধারণ পাল্টা উদাহরণ (আমি নিশ্চিত যে আরও ভাল আছে): প্রোগ্রামিং ভাষার বাক্য গঠন টেবিলগুলি জটিল বড় কাঠামো যা প্রায়শই হার্ড-কোডড থাকে। পার্ল উত্স কোড থেকে একটি উদাহরণ দেখুন ।

পরিবর্তে আমি প্রথমে জিজ্ঞাসা উপর ফোকাস করা হবে:

কতবার ডেটা পরিবর্তন হয়?
কার এটি পরিবর্তন করার প্রয়োজন হতে পারে?

যদি আমি "আমার অ্যাপ্লিকেশনটির নতুন সংস্করণ স্থাপন করতে চাই" তার চেয়ে বেশি "কখন" হয় তার উত্তর যদি আপনার হয় তবে আপনার ডেটা হার্ড কোড করা উচিত নয়।

যদি "কে এটি পরিবর্তন করে" এর উত্তর যদি "প্রোগ্রামার ছাড়াও অন্য কেউ হয়", তবে আপনার হার্ড ডেটা কোড করা উচিত নয়।

একটি ছোট্ট দোকানে, কোডার এবং ব্যবহারকারীর মধ্যে পার্থক্যটি অদৃশ্য হয়ে যায় এবং "স্থাপনার" ধারণাটিও অদৃশ্য হয়ে যায়। এই ক্ষেত্রে আপনি নিজের ডোমেনের রাজা এবং আপনি যা খুশি তাই করতে পারেন can

তবে সেই পরিস্থিতিতেও, সহযোগিতা করার প্রয়োজনীয়তা উপস্থিত হতে পারে এবং প্রোগ্রামিংকারীরা সাধারণত যে কনভেনশনটি অনুসরণ করে কোনও কাস্টম অ্যাপ্লিকেশন অনুসরণ না করে তা কঠিন হতে পারে।

— এক্স-কোড
সূত্র

6

প্রায়শই যেভাবে প্রশ্ন করা হয় তার অনুরূপ, আরেকটি প্রশ্ন, "এটির পরিবর্তনের দরকার কত দ্রুত হয়?" গেটিং ফ্যাক্টরটি আপনার ব্যবহারকারী বেস জুড়ে স্থাপন করতে কত সময় নেয় তা হতে পারে। সেন্ট্রালাইজড সার্ভার সফ্টওয়্যারটির জন্য, উত্তরটি কয়েক মিনিট হতে পারে তবে ক্ষেত্রের মোবাইল অ্যাপ্লিকেশনগুলির জন্য, এটি কয়েক সপ্তাহ সময় নিতে পারে।

— কৌতূহল রাব্বিট

পার্ল উদাহরণস্বরূপ, আমি এটি হিসাবে রাখব an array with a few values, কয়েকটি মৌলিক ডেটা ধরণের 377-ইশ সারি। কারও কারও কাছে "কয়েক" এর চেয়ে বেশি হতে পারে তবে এটি এখনও বেশ ছোট। আমার অনুরূপ এখনও কিছুটা কম ফ্ল্যাট কাঠামো হার্ডকডযুক্ত। এটি যদি এক হাজার + সারি হত তবে আমি সম্ভবত এটিকে হার্ডকোড করতে আরও নারাজ।

— ডেনিস

14

আমি তৃতীয় বিকল্পটি নিয়ে যাব: একটি কনফিগার ফাইল!

আমি যে অ্যাপ্লিকেশনগুলিতে কাজ করি (জাভাতে, তাই আমার সমস্ত উদাহরণ জাভা + স্প্রিং ব্যবহার করা হয়), এই জাতীয় মানগুলি সাধারণত কনফিগার ফাইলগুলিতে সংরক্ষণ করা হয় এবং অ্যাপ্লিকেশন শুরু হওয়ার পরে তাদের প্রয়োজনীয় কোডগুলিতে (স্প্রিংয়ের মাধ্যমে) ইনজেক্ট করা হয়। একটি সম্পত্তি ফাইলে:

motorFramesString=412T, 413T, ...

বসন্ত কনফিগারেশনে:

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

এর সুবিধাটি হ'ল আপনি পুনর্নির্মাণ ব্যতিরেকে সহজেই যথেষ্ট পরিমাণে স্থির মানগুলি পরিবর্তন করতে বা যুক্ত করতে পারেন এবং আপনার (সম্পর্কিত) ডাটাবেসটিকে রেফারেন্স ডেটা পূরণ করার বিষয়ে আপনাকে কোনও উদ্বেগ করতে হবে না (যেহেতু এটি মনে হয় যে উদ্বেগ, এবং হয়ত না সবকিছু চাহিদা ডাটাবেসের মধ্যে হতে যাহাই হউক না কেন)।

হিসাবে কেন এই মান একটি রেফারেন্স টেবিল পরিবর্তে একটি কনফিগ ফাইলে যেতে হবে: আপনি কি বা বেশিরভাগই কোডে এই মান ব্যবহার করার পরিকল্পনা, বেশিরভাগ ডাটাবেসের মধ্যে? আপনার যদি অনেক বিদ্যমান ক্যোয়ারী থাকে এবং এই মানগুলির উপর নির্ভর করে এমন দৃষ্টিভঙ্গি এবং পদ্ধতিগুলি থাকে তবে এগুলি ডাটাবেসে রেফারেন্স ডেটা হিসাবে রাখাই ভাল হবে কারণ কনফিগারেশন ফাইলগুলি থেকে লোড করা এবং প্রতিটি সম্ভাব্য ক্যোয়ারি / প্যারামিটার হিসাবে তাদের পাঠানোর চেয়ে এটি সহজ it's দেখুন / পদ্ধতি যা তাদের উল্লেখ করে। মানগুলি যদি বেশিরভাগ অ্যাপ্লিকেশন কোডে ব্যবহৃত হয় তবে কনফিগার ফাইলটি সম্ভবত আরও ভাল পছন্দ।

আপনি যা সংযুক্ত করেন তার মতো আরও জটিল উদাহরণ, সম্পত্তি সহ বা বহির্মুখী কিছুও করা যায়।

প্রোডাক্ট.প্রোপার্টিগুলিতে:

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>

এর সম্পর্কে দুর্দান্ত জিনিসটি হ'ল যদি আপনার উত্স ডেটা স্প্রেডশিট হয় (যেমন আপনি যে প্রশ্নটির সাথে লিঙ্ক করেছেন) আপনি এক্সেলটিতে ম্যাক্রোগুলি স্বয়ংক্রিয়ভাবে বৈশিষ্ট্য এবং বসন্তের স্নিপেটগুলি তৈরি করতে পারেন।

— FrustratedWithFormsDesigner
সূত্র

আপনি ফ্রেমের উদাহরণে থাকাকালীন এটি মোটামুটি সহজ (শুধুমাত্র একটি স্ট্রিংয়ের মান)। আপনার দৃষ্টিভঙ্গিটি কীভাবে মিশ্রিত ভেরিয়েবলগুলির এন-টুপলগুলি রয়েছে (আমার প্রশ্নের নীচে লিঙ্কযুক্ত) বিকল্পগুলির সারণির জন্য একই হবে?

— ডেনিস 18

@ ডেনিস: আরও জটিল উদাহরণ যুক্ত করেছেন।

— হতাশ

8

একটি কনফিগার ফাইল কেবল একটি ধরণের ডিবি।

— ডগএম

3

@ ডগএম, আমি সম্মত, তবে ওরাকলে একটি কনফিগার টেবিল স্থাপন এবং একটি সাধারণ এক্সএমএল কনফিগার ফাইলের মধ্যে পার্থক্য রয়েছে। কনফিগ ফাইলটিতে সংস্করণ নিয়ন্ত্রণ দ্বারা নিয়ন্ত্রিত হওয়ার গুণ রয়েছে। কনফিগার ফাইলটি একটি মাঝারি স্থল এবং কোডারদের আরও কনফিগার ডেটা আলাদা করতে উত্সাহ দেয়। আমি বাস্তববাদী পরিস্থিতিগুলি ভাবতে লড়াই করে যাচ্ছি যেখানে সময়টি ভাল হয় না

— ম্যাকটল

2

@gbjbaanb: বেশিরভাগ অ্যাপ্লিকেশনগুলির জন্য একটি আরডিবিএমএস হ'ল WAAAAAY ওভারকিল এমনকি অন্যথায় বেশ বিস্তৃত সিস্টেমগুলির জন্যও। এগুলি উল্লেখ করা উচিত নয় যে এগুলি ধীর এবং এগুলি বজায় রাখতে এবং সংহত করার জন্য পর্যাপ্ত পরিশ্রমের প্রয়োজন। "ini" ফাইলগুলি কোনও ধরণের সুরক্ষা সরবরাহ করে না, আপনাকে নিজেই পার্সার লিখতে হবে এবং আপনাকে নিজের ধরণের চেক লিখতে হবে। কমপক্ষে নেট এ, এক্সএমএল কনফিগারেশন ফাইলগুলি আপনার পছন্দের বিকল্পগুলির যে কোনও দ্বারা প্রদত্ত সমস্ত সুবিধা মূলত বিনামূল্যে পান। সুতরাং আপনার দাবি যে কোনও এক্সএমএল কনফিগারেশন ফাইল সর্বদা একটি খারাপ পছন্দ আরও ভুল হতে পারে না।

— ডঙ্ক

10

আমি মনে করি প্রশ্নের ভিত্তিটি ঠিক সঠিক নয়। বিভাজক ফ্যাক্টরটি রেকর্ডগুলির পরিমাণ পরিবর্তন করতে হবে যা নয় , পরিবর্তনের ফ্রিকোয়েন্সি পাশাপাশি কে তাদের পরিবর্তন করে।

ফ্রিকোয়েন্সি

যখন ডেটা অস্থির হয় , এই অর্থে যে এটি প্রায়শই পরিবর্তিত হয় এবং সফ্টওয়্যারটির প্রকাশের চক্রের বাইরে, হার্ড-কোডিং মান বা কনফিগারেশন ফাইলের বাইরেও এটি কনফিগার করা সম্ভব হয়। একটি ডাটাবেস এখানে অর্থবোধ করে, বিশেষত যদি অ্যাপ্লিকেশন নিজেই এটি বজায় রাখতে সক্ষম হয়।

কে

যখন কোনও গ্রাহকের ডেটা পরিবর্তন করতে সক্ষম হওয়া দরকার তখন এটি ব্যবহারকারী-বান্ধব উপায়ে এবং একটি রিলিজ চক্রের বাইরে পরিবর্তিত হওয়া দরকার।

সাধারণ সূত্র

এখানে সাধারণ থ্রেডটি হ'ল যখন কোনও সফ্টওয়্যার রিলিজের বাইরে ডেটা পরিবর্তন করা দরকার, তখন এটি একটি ডাটাবেসে সংরক্ষণ করা উচিত। একটি রিলিজের সময় ডেটাবেসগুলি আপগ্রেড করা হতে পারে, তবে ডেটা পুনরায় সেট করা বা ভারী পরিবর্তন না করেই বেঁচে থাকে। যখন কোনও গ্রাহকের ডেটা পরিবর্তন করতে (বা কার্যকারিতা কনফিগার করতে) সক্ষম হতে হবে, তখন এটি একটি দুর্দান্ত ফ্রন্ট এন্ডের সাথে একটি ডাটাবেসে সংরক্ষণ করা উচিত যা ইডিয়ট-প্রুফ is

পরীক্ষামূলক

ইউনিট পরীক্ষা লিখতে ভুলবেন না যা বিভিন্ন কনফিগারেশনে আপনার সফ্টওয়্যারকে বৈধতা দেয়। হতে পারে আপনার গ্রাহক একটি alচ্ছিক প্রম্পট চালু করে, বা এক মিটার বারো ফুট সমানকে পুনরায় সংজ্ঞা দেয়। পরিবর্তনটি কতটুকু যুক্তিসঙ্গতই হোক না কেন, আপনার সফ্টওয়্যার যদি এটির অনুমতি দেয় তবে এটি আরও ভালভাবে যাচাই করা যায় যে পরিবর্তনটি যতই অনড় হোক না কেন প্রত্যাশা অনুযায়ী কাজ করে।

4

এটি পরিবর্তনগুলির ফ্রিকোয়েন্সি বা ডেটা পরিমাণের পরিমাণ নয় যে কোথায় ডেটা সংরক্ষণ করবেন তা সিদ্ধান্ত নেয়।

প্রোগ্রামটি চালানোর জন্য যদি ডেটা প্রয়োজন হয় তবে এটি প্রোগ্রাম কোডের একটি অংশ, তাই এটি একটি ধ্রুবক হিসাবে সংরক্ষণ করুন। অন্যান্য সমস্ত ডেটা ডাটাবেসে যায়।

অবশ্যই কনফিগারেশন ফাইল, চিত্র, শব্দ, ইত্যাদি সাধারণত ফাইল সিস্টেমে ভালভাবে সঞ্চিত থাকে।

— winkbrace
সূত্র

আমি একটি কল-সেন্টার-সহায়তা প্রোগ্রাম তৈরি করেছি যা সম্পূর্ণ ডিবি চালিত ছিল; "কোড চালানোর জন্য" ডেটা প্রয়োজন ছিল, তবে এটি সংকলন করা অযৌক্তিক হত।

— ডগএম

1

আমি 8 বছর ধরে ওরাকল বিকাশকারী ছিলাম, তবে আমি এখনও এমন অ্যাপ্লিকেশন পছন্দ করি না যার অন্তর্নিহিত ডাটাবেসের সাথে এমন শক্ত সংযুক্তি রয়েছে।

— উইঙ্কব্র্যাস

2

এমনকি যদি সামান্যতম সুযোগও পাওয়া যায় তবে আপনি কোনও অ্যাপ্লিকেশন পুনর্নির্মাণের ফলস্বরূপ কোনও ফোন কল পাবেন কারণ হার্ড-কোডেড কিছু পরিবর্তিত হয়েছে, তবে এটি হার্ড-কোড করবেন না। খুব কমপক্ষে এটি একটি কনফিগার ফাইল বা ডিবি টেবিলে রাখুন। এটি প্রয়োজনীয়ভাবে বজায় রাখতে আপনার কোনও ইউআই সরবরাহ করতে হবে না, তবে একটি ডায়াল করে ডায়াল করে কোনও কনফিগার ফাইল পরিবর্তন করা বা কোনও টেবিলের উপর এসকিউএল আপডেট আপডেট চালানো পুরো শুটিং ম্যাচটি পুনর্নির্মাণে অবশ্যই পছন্দনীয়।

— অ্যালান বি
সূত্র

1

পার্থক্যটি সত্যই কিছুটা ধূসর অঞ্চল, তবে এই ধরণের বিষয়ে আমার দৃষ্টিভঙ্গি হ'ল: ডেটা উত্পাদনে কি পরিবর্তন হয় "? কোনও পরিবেশের পরিবেশে মোতায়েনের পরে যে কোনও কিছু বদলে যায় তা এমনকি ডাটাবেসে থাকা উচিত, এমনকি এমন জিনিসগুলির ক্ষেত্রেও যা খুব কমই পরিবর্তিত হতে পারে।

সুতরাং আপনার যে প্রশ্নটি জিজ্ঞাসা করা উচিত তা "এটি কতবার পরিবর্তিত হবে?" নয়, তবে "এটি কী পরিবর্তন হতে পারে?"। উত্পাদনের পরিবেশে যদি কোনও সম্পত্তির মান একই কোড পুনরাবৃত্তির ( কোডে অন্য কোনও কিছুর ছোঁয়া ছাড়াই) পরিবর্তিত হতে পারে , তবে এটি ডাটাবেসে যায়।

— Thyamarkos
সূত্র

0

আপনি যা অনুপস্থিত তা হ'ল "প্রোগ্রাম কন্ট্রোল" টাইপ তথ্যটি বলছে সর্বোচ্চ বাফার আকার, ক্রমে বড় আকারের আইটেমের সংখ্যা, পর্দার জন্য সর্বাধিক পৃষ্ঠার আকার সর্বদা প্রোগ্রামে বা কনফিগারেশনের ফাইলের মধ্যে হার্ড কোডড better

আপনি যদি ডাটাবেসে এই ধরণের ডেটা রাখেন তবে সর্বদা কেউ ফ্লাইতে এটি পরিবর্তন করে এবং সিস্টেমের আচরণে সম্পূর্ণরূপে পরিবর্তনের সম্ভাবনা থাকে।

অন্য সমস্যাটি হ'ল উত্স নিয়ন্ত্রণ / পরিবর্তন পরিচালনা / স্বয়ংক্রিয়ভাবে বিল্ড সিস্টেমগুলি ব্যবহার করা উচিত যা আপনার ব্যবহার করা উচিত database

— জেমস অ্যান্ডারসন
সূত্র

0

ডাটাবেসটিতে আপনার যে জিনিসটি রাখা উচিত তা হ'ল ডেটাবেস অ্যাক্সেস করার জন্য প্রয়োজনীয় বিশদ।
সর্বোপরি সেই একই ডাটাবেসের জন্য সংযুক্ত স্ট্রিং, ব্যবহারকারীর নাম এবং পাসওয়ার্ড পুনরুদ্ধার করতে আপনার যদি ডাটাবেস অ্যাক্সেস করতে চান তবে আপনার কাছে একটি ক্যাচ -২২ রয়েছে।

হার্ডকোড এটা? হুম, আপনি অ্যাপ্লিকেশনটি সহ কিছু প্রকারের ডাটাবেস ইনস্টল এবং শিপ ব্যবহার করছেন যদি কাজ করতে পারে।
কনফিগারেশন ফাইল? আরও প্রতিশ্রুতিশীল তবে অ্যাকাউন্ট সুরক্ষা সম্পর্কে কী?

অবশ্যই আপনি এনক্রিপ্ট করা আকারে সেই কনফিগারেশন ফাইলে ডাটাবেস তথ্য সংরক্ষণ করতে পারেন, তবে তারপরে আপনার ডিক্রিপশন কীগুলি কোথাও সঞ্চিত থাকা দরকার এবং এটি অবশ্যই হার্ডকোড করা উচিত।

তা ছাড়াও এমন কিছু জিনিস রয়েছে যা কখনই বদলায় না। প্রাকৃতিক ধ্রুবকগুলির মতো জিনিস (জি, পাই, ই, আপনি এটি নাম দিন), জিনিসগুলি ইমেল বৈধতার মতো কিছু নির্দিষ্ট নিয়মিত অভিব্যক্তি পছন্দ করে।

— jwenting
সূত্র