কনফিগারেশন ডেটা: একক-সারি টেবিল বনাম নাম-মান-জুটি টেবিল

Question

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

1. একক-সারি টেবিল

     CompanyName  |  StartFullScreen  |  RefreshSeconds  |  ...
   ---------------+-------------------+------------------+--------
     ACME Inc.    |        true       |       20         |  ...
   

2. নাম-মান-যুগল টেবিল

     ConfigOption   |   Value
   -----------------+-------------
    CompanyName     | ACME Inc.
    StartFullScreen | true (or 1, or Y, ...)
    RefreshSeconds  | 20
    ...             | ...
   

আমি বন্যের উভয় বিকল্প দেখেছি এবং উভয়েরই সুস্পষ্ট সুবিধা এবং অসুবিধা রয়েছে, উদাহরণস্বরূপ:

• একক-সারি সারণীগুলি আপনার কাছে থাকা কনফিগারেশন বিকল্পগুলির সংখ্যা সীমিত করে দেয় (যেহেতু একটি সারিতে কলামগুলির সংখ্যা সাধারণত সীমাবদ্ধ থাকে)। প্রতিটি অতিরিক্ত কনফিগারেশন বিকল্পের জন্য একটি ডিবি স্কিমা পরিবর্তন প্রয়োজন।
• একটি নাম-মান-জুটির টেবিলটিতে সবকিছু "স্ট্র্যলি টাইপড" থাকে (আপনাকে আপনার বুলিয়ান / তারিখ / ইত্যাদি প্যারামিটারগুলি এনকোড / ডিকোড করতে হয়)।
• (আরো অনেক)

উন্নয়ন বিকল্পের মধ্যে কোন preক্যমত্য রয়েছে সে সম্পর্কে কোন বিকল্পটি পছন্দনীয়?

Comments

'উল্লম্ব' পদ্ধতির বিভিন্ন ধরণের ডেটা ধরণের কোনও কারণ নেই। প্রতি সারি ইনট, ফ্লোট এবং পাঠ্য কলাম যুক্ত করুন। টাইপ-নির্দিষ্ট ফাংশনগুলি ব্যবহার করে এর থেকে মানগুলি সংরক্ষণ / লোড করুন, যেমন 'SaveConfigInt (' ক্ষেত্র ', এন)'

— গ্র্যান্ডমাস্টারবি

এটি সম্পর্কে জিজ্ঞাসা করার জন্য একটি দুর্দান্ত স্ট্যাকওভারফ্লো প্রশ্ন রয়েছে এবং শীর্ষের উত্তরটি উভয় পদ্ধতিরই পক্ষে মতামত দেয়। stackoverflow.com/questions/2300356/…

— কেভিন

পদ্ধতির 3: JSON বা YAML এর মতো একটি সাধারণ ডেটা ইন্টারচেঞ্জ ফর্ম্যাট সহ একক কলাম / একক সারি। উভয় পন্থা থেকে সুবিধা একত্রিত।

— schlamar

এক্সএমএল / জেএসনযুক্ত <config> <CompanyName> ACME Inc. </CompanyName> <স্টার্টফুলস্ক্রিন> সত্য </ স্টার্টফুলস্ক্রিন> <<< রিফ্রেশসেকেন্ডস </config> এবং জটিল কোড সহ একক-সারি টেবিল ব্যবহার সম্পর্কে কী? ব্যবসায় স্তর স্তর অবজেক্ট?

— জন

@ জন: ভাল ধারণা, যদি শ্রেণিবদ্ধ কাঠামোর প্রয়োজন হয়। যদি তা না হয় তবে এটি যুক্ত জটিলতার সাথে কেবল বিকল্প 2।

— হেইনজি

Answer 1

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

সুতরাং আপনি কি ক্লাসের সদস্যদের উপর একটি অভিধান / মানচিত্র ব্যবহার করবেন? সম্ভবত আপনি যদি না ভাবেন যে পরিমাণ উপাত্ত উপস্থাপন করা হবে তা সম্পূর্ণরূপে অভিযোজিত, যেমন নাম-মান জোড়ার টেবিল থাকার মতো না not

Comments

সংরক্ষণ করা তথ্য যদি ব্যবহারকারী-সংজ্ঞায়িত হয়? অর্থাত্ কোনও ইউআইয়ের কথা ভাবেন যেখানে ব্যবহারকারী ক্ষেত্রের লেবেল, এটি যে ধরণের ডেটা ধারণ করবে ইত্যাদি নির্দিষ্ট করে একটি "ক্ষেত্র" তৈরি করতে পারে That এর অর্থ কোড থেকে ডিডিএল বিবৃতি কার্যকর করা হবে। আপনি এখনও বিকল্প 1 দিয়ে যেতে চান?

— ডেভনালাইস্ট

@ দেওয়ানালিস্ট না, যদি ডেটা উপাদান থেকে উপাদানগুলিতে পরিবর্তিত হতে পারে, তবে এটি উপস্থাপনের জন্য একটি স্ট্যাটিক টেবিল তৈরি করার চেষ্টা করার কোনও মানে হবে না। সেক্ষেত্রে দ্বিতীয় বিকল্পটি ব্যবহার করা ভাল।

— নীল

Answer 2

আমি সাধারণত বিকল্প 2 দিয়ে যাব তবে ডেটা টাইপ প্রয়োগের জন্য আমার একাধিক কলাম থাকবে

ConfigOption   |   textValue    |   DateValue   |   NumericValue

বিকল্প 1 এর অতিরিক্ত বেনিফিট রয়েছে যা আপনি খুব সহজেই একটি Activeকলাম যুক্ত করে পুরো কনফিগারেশনগুলিকে "অদলবদল" করতে পারেন ।

Comments

আপনি কনফিগারেশনের নিষ্ক্রিয় করা (বিকল্প 1) করার অনুমতি, অন্তত এটা একটা করতে যাচ্ছেন এমন activatedOnটাইমস্ট্যাম্প, তাই আপনি বলতে পারেন যখন এটা সক্রিয় করা হয়েছে। এবং যদি আপনি বিকল্প 2 নিয়ে যাচ্ছেন ... তবে একাধিক কলামে মানগুলি সংরক্ষণ করা শেষ হলে (বা এটি ওরাকল, যেখানে (আপাতদৃষ্টিতে) নাল এবং একটি খালি স্ট্রিং সমতুল্য হয়) কি হবে?

— ক্লকওয়ার্ক-মিউজিক

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

— মরনস

একটি EATV (সত্তা-গুণ-প্রকারের মান) স্কিমা তৃতীয় স্বাভাবিক ফর্মটি ভেঙে দেয়; টাইপ কলামটি টাইপ কলামটি বর্ণনা করে এমন মান কলামের মাধ্যমে কেবল পরোক্ষভাবে টেবিলের প্রাথমিক কী সম্পর্কিত। তদতিরিক্ত, গতিশীল ধরণের স্টোরেজ এবং তাত্ক্ষণিকতা খুব বেশি সমাধান করে না; যদি getConfigValue () পদ্ধতিটি যে কোনও প্রকারকে ফিরিয়ে দিতে পারে, তবে অবশ্যই অবজেক্টটি প্রত্যাবর্তন করতে হবে (বা কোনওভাবে প্রত্যাশিত প্রকারটি দেওয়া হবে) যা রানটাইমটিতে এখনও মূল্যায়ন করতে হবে।

— কিথস

আমি দেখেছি এমন সফ্টওয়্যারগুলিতে এভারটাইম বিকল্প 1 প্রয়োগ করা হয়েছে, এটি বিকল্প 2 এ রূপান্তরিত করতে হয়েছিল O বিকল্প 2 সময়ের সাথে সাথে বজায় রাখা সহজ, প্রথমবার সঠিকভাবে প্রয়োগ করতে আরও একটি স্পর্শ লাগে। বিকল্প 1 কার্যকর এবং কার্যকর করা সহজ তবে সময়ের সাথে সাথে রক্ষণাবেক্ষণ ভয়ঙ্কর হয় যদি না আপনার সফ্টওয়্যারটি বাড়ার কোনও সম্ভাবনা না থাকে।

— জিমি হোফা

Answer 3

আমার জন্য, আপনি একক-সারিতে যান বা EAV আপনি কীভাবে সেগুলি গ্রাস করতে চান তার উপর নির্ভর করে।

EAV এর শক্তি হ'ল কাঠামোর কোনও পরিবর্তন ছাড়াই নতুন ডেটা যুক্ত করা যায়। এর অর্থ হ'ল যদি আপনি একটি নতুন কনফিগারেশন মান চান, আপনি কেবল এটি টেবিলের সাথে যুক্ত করুন এবং কোডে আপনি এটি কোথায় চান তা টানুন এবং আপনার ডোমেন, স্কিমা, ম্যাপিং, ডএল কোয়েরিতে একটি নতুন ক্ষেত্র যুক্ত করার দরকার নেই ইত্যাদি

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

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

প্রধান অসুবিধাটি হ'ল প্রতিটি নতুন মানের জন্য একটি কাঠামোগত পরিবর্তন প্রয়োজন; নতুন ডিবি কলাম, ডালে নতুন কলাম (ম্যাপিং বা এসকিউএল কোয়েরি / এসপি) হয়, নতুন ডোমেন কলাম, ব্যবহারের সঠিকভাবে পরীক্ষা করার জন্য প্রয়োজনীয়।

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

সংক্ষেপে, কনফিগারেশন সংরক্ষণের জন্য একটি EAV স্কিমা সত্যিই এটি সমাধান করার পরিকল্পনা করে এমন সমস্যার সমাধান করে না, এবং বেশিরভাগ ওয়ার্কআরউন্ডগুলি যে সমস্যার সমাধান করে তা DRY লঙ্ঘন করে।

Answer 4

বিশেষত কনফিগারেশন মানগুলির জন্য, আমি বলব - একক সারির সাথে যান। আপনি যদি বর্তমানে বিকাশের মধ্য দিয়ে যাচ্ছেন না, তবে এই কলামগুলি যেভাবেই বদলাতে চলেছে?

বৃহত্তর (আর) রিলিজের মধ্যে ডাউনটাইমটিতে আপনার সম্ভবত না হওয়ার মতো এক্সটেনসিবিলিটির কোডের চেয়ে মানগুলির ডেটাটাইপটি সুরক্ষিত করা সবচেয়ে ভাল । এছাড়াও, একটি একক কলাম যুক্ত করা বা অপসারণ করা কেবল সেখানে সবচেয়ে সহজ স্থানান্তর সম্পর্কে। নতুন কনফিগারেশন বিকল্প তৈরি করার সময় আমি মাথা ব্যথার ঝোঁক ছাড়ি না।

অতিরিক্তভাবে, আপনি বলেছিলেন যে "ব্যবহারকারীরা" কোনও ক্যাপ না দিয়েই এই বিকল্পগুলি কনফিগার করতে পারেন। তারা কি প্রতি ব্যবহারকারী কনফিগারেশন? যদি তা হয় তবে আমি আরও দৃ strongly়তার সাথে তর্ক করব যে কনফিগারেশন বিকল্পগুলি কলামগুলিতে থাকা উচিত - ব্যবহারকারী হিসাবে একক সারি। এটি পরে রক্ষণাবেক্ষণের অনেক মাথাব্যথা বাঁচাবে।

Answer 5

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

যদি আপনার ক্লায়েন্টরা JSON টুকরা প্রক্রিয়া করতে না পারে তবে নতুন ক্লায়েন্ট পান।

Answer 6

একক সারি পেশাদার: ভাল সংজ্ঞায়িত। কনস: কনফিগারেশন পরিবর্তন করা ব্যথা হতে পারে। ডিবি স্থানান্তর ইত্যাদি।

সত্তা-মান পেশাদাররা: সুপার নমনীয়, আপনার কনফিগার বিকশিত সমর্থন করে। কনস: রেফারেন্সিয়াল অখণ্ডতা? আপনার কোডটিতে আরও কিছু পরীক্ষা করার আগে আপনার সম্পত্তিটি কিছু করার আগে তা বিদ্যমান আছে কিনা তা দেখতে।

আমি মঙ্গোর মতো একটি সম্পর্কহীন ডিবি-র সমর্থিত 2 পদক্ষেপ নেব। এমন কিছু যদি থাকে তবে আপনি নিশ্চিত হয়ে যেতে পারেন, এর পরিবর্তন।

Answer 7

ব্যবহার উভয়!

কোন বিকল্পগুলির একাধিক উদাহরণ থাকতে পারে এবং কী বিকল্পগুলি জেনেরিক তা বাছাই করুন।

একক সারি সারণী (কনফিগারেশন)

  id  |  company_name  |  start_fullscreen  |  refresh_seconds  |  ...
------+----------------+--------------------+-------------------+-------
  4   |  ACME Inc.     |  true              |  20               |  ...

নাম-মান-জুটি সারণী (বিকল্পগুলি)

  name             |  value          | update_time  
-------------------+-----------------+--------------
  generic_option_1 |  Option 1 Value | timestamp    
  generic_option_2 |  Option 2 Value | timestamp    
  generic_option_3 |  Option 3 Value | timestamp    
  configuration    |  4              | timestamp    
  ...              |  ...            | ...          

আমি মনে করি এটি আরও নমনীয়।