স্ট্যাটিক ডেটা কোনও ডাটাবেসে বা অন্য কোথাও সংরক্ষণ করা উচিত?


20

আমি তাদের মুহুর্তে কয়েকটি সফ্টওয়্যার নিয়ে কাজ করছি এবং নিশ্চিত নয় যে এটি দিয়ে কোন রুটটি নিয়ে যাবে। মোবাইল ডিভাইসে কোথাও সঞ্চয় করার জন্য আমার কাছে কিছু ডেটা রয়েছে। ডেটা কখনই পরিবর্তিত হবে না এবং এর একটি শ্রেণিবিন্যাস সম্পর্কিত সম্পর্ক রয়েছে এবং এটি প্রদর্শনকে জনপ্রিয় করতে ব্যবহৃত হবে। এই ডেটা একটি যুক্তিসঙ্গত পরিমাণ আছে।

আমার কাছে নিম্নলিখিত বিকল্পগুলি রয়েছে:

  1. এনাম / অবজেক্টের একটি সেট
  2. একটি এক্সএমএল ফাইল
  3. এম্বেড করা এসকিউএল ডাটাবেস

এই বিশেষ ক্ষেত্রে আমি মনে করি যে enums বিকল্পটি সর্বনিম্ন কাজ, তবে কোডটি এমবেড করা ডেটা থেকে আমি গন্ধ পাচ্ছি।

এক্সএমএল ফাইলটি আমার মনে হয় সর্বাধিক বোধগম্য, তবে এটি বিশদকরণটি এমন একটি উত্স হিট হবে যা বর্জ্যের মতো মনে হয় কারণ এটি 'কখনই' পরিবর্তন হবে না।

ডাটাবেসটিতে কম পারফরম্যান্সের হিট সরবরাহ করা উচিত, তবে স্থির তথ্যের জন্য ওভারকিলের মতো মনে হয়।

এখানে সঠিক নকশার পথটি কোনটি?

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


2
এই প্রতিটি পদ্ধতির মধ্যে পারফরম্যান্স-ভিত্তিক সময় সম্মান কী? আপনি কি আগে তাদের পরীক্ষা / বেঞ্চমার্ক করেছিলেন?
মাহদী

1
"খুব কমই পরিবর্তন" - রানটাইমের সময় কি এটি পরিবর্তন করা দরকার? অ্যাপ্লিকেশন শুরুতে? বা এটির জন্য নতুন বিল্ড গ্রহণযোগ্য?

এটি রানটাইম বা স্টার্ট আপের সময় কখনও পরিবর্তন হবে না। একটি নতুন বিল্ড গ্রহণযোগ্য হবে
কার্লিপল

আমি মনে করি না যে এখানে 'স্পষ্ট' উচিত। আপনি ডেটার পরিমাণ, এর প্রকৃতি এবং এটি কীভাবে ব্যবহৃত হয় সে সম্পর্কে উভয়ই সামান্য তথ্য সরবরাহ করেছেন। আমি উপরোক্ত সমস্ত কিছু অতীতেও করেছি ... আপনি কোন পথে যাচ্ছেন তা নির্ভর করে
গ্র্যান্ডমাস্টারবি

এনামস / অবজেক্টস হিসাবে এম্বেড থাকা ডেটা থাকা অপরিহার্যভাবে ভুল নয়, এটি খুব সহজ সরল, পরিষ্কার এবং সবচেয়ে সঠিক হতে পারে। এটি ভবিষ্যতে ডেটা পরিবর্তনের কারণ হতে পারে তার উপর নির্ভর করে।
জ্যাকবিবি

উত্তর:


18

আমি এই জন্য একটি অবজেক্ট ব্যবহার করব।

আপনি বলেছিলেন যে ডেটা কখনই পরিবর্তন হবে না, তাই আপনি সহজেই অ্যাপ্লিকেশনটিতে এটি সঞ্চয় করতে পারেন। ডাটাবেস ওভারকিল হবে এবং আকার বাড়িয়ে তুলবে।
এক্সএমএল ফাইলটি কিন্ডার ওভারকিলও হবে এবং আকারও বাড়িয়ে তুলবে।

সুতরাং আমার মতে সেরা বিকল্পটি হবে একটি এনাম বা অবজেক্ট।


2
এটাই আমি সৎ হওয়ার প্রতি ঝোঁক দিচ্ছি, আমি পছন্দ করি না এমন একমাত্র বিষয়টি কোডের সাথে ডেটা মেশানো। কখনও কখনও আমাকে স্বীকার করতে হয় যে সর্বোত্তম পথটি যদিও সর্বদা আমার ওসিডির সাথে খাপ
খায়

একটি এনাম খারাপ কিছুই নয়;) আপনার কাছে কী ধরণের ডেটা আছে?
কেনার্ড

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

11

এটা কি কখনও বদলাবে না, নাকি বদলে যাবে? আপনার কাছে একটি ভাল প্রতিক্রিয়া পাওয়ার আগেই সত্যিই এই প্রশ্নের উত্তর দিতে হবে।

স্থিতিশীল ডেটা যা কখনই পরিবর্তন হয় না (যেমন সপ্তাহের নামের দিনগুলি) কোডে যেতে ভাল;

কার্যত কখনও পরিবর্তন হয় না এমন ডেটা (যেমন আপনার সার্ভারের ডিএনএস নাম) কোডে যেতেও ভাল, যদি এটির পরিবর্তনের প্রয়োজন হয় তবে এটি এত বিরল যে কোনও কোড আপডেট ঠিক আছে।

যে ডেটা পরিবর্তন হয় না, তবে সম্ভবত (পর্যায়ক্রমিক রিফ্রেশগুলির মধ্যে সময়ের বিলম্ব) সম্ভবত কোনও সহজেই পরিবর্তিত স্থানে যেমন স্থানীয় কনফিগার স্টোর (স্ক্লাইট বা এক্সএমএল, কোনও আসল পার্থক্য দেয় না) সেরা is

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


এই ক্ষেত্রে 'কখনই' হতে চলেছে সে সম্পর্কে আমি কিছু তথ্য যুক্ত করেছি
কার্লিপল

@ কর্যলিপল তাদের কোডে বাঁধলো, যদি তারা পরিবর্তন করে তবে আপনার সম্ভবত কোডটি আপডেট করতে হবে। আপনার কোডিং / পরীক্ষা সহজতর করে যদি কেবল সেগুলিকে একটি স্ক্লাইট / এক্সএমএল ডিবিতে রাখুন।
gbjbaanb

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

@ পিটারবি এটি আমার মাথার উপরের অংশের এক উদাহরণ মাত্র। 'সপ্তাহে বেশিরভাগ দিন' কী আপনার জন্য নিট বাছাইযোগ্য উদাহরণ হতে পারে?
gbjbaanb

@gbjbaanb যতক্ষণ না আমরা অন্যান্য গ্রহগুলির উপনিবেশ শুরু করি ততক্ষণ অপেক্ষা করুন। তাহলে আপনি কি করতে যাচ্ছেন? / s
মিনিরাগনারোক

5

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


এই ক্ষেত্রে 'কখনই' হতে চলেছে সে সম্পর্কে আমি কিছু তথ্য যুক্ত করেছি। আপনার ইনপুট জন্য আপনাকে ধন্যবাদ
কার্লিপল

আসুন লিঙ্গ এম (আলে) এবং এফ (ইমেল) সংরক্ষণের জন্য একটি টেবিল "লিঙ্গ" তৈরি করুন, তারা কি পরিবর্তন করে?
মার্টিন ফেফার

4

কোনও ডেটা জিজ্ঞাসা করার প্রশ্নটি এটি পরিবর্তন হবে কিনা তা নয়; আপনি সম্ভবত জানেন না, এবং আপনি তা করলেও উত্তরটি সম্ভবত বিভ্রান্তিকর হবে।

জিজ্ঞাসা করা প্রশ্নটি হ'ল, যখন এটি পরিবর্তন হয়, কে এটি পরিবর্তন করতে হবে:

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

মঙ্গলবার সাধারণত একটি এনাম হওয়া উচিত কারণ এটি কখনই পরিবর্তন করতে পারে না। তবে যদি কোনও পাগল স্বৈরশাসক দায়িত্ব গ্রহণ করেন এবং মঙ্গলবার তার নামে নামকরণের দাবি করেন তবে সফ্টওয়্যার লেখক হিসাবে আপনাকে এটি পরিবর্তন করতে হবে (বা হাঙ্গরকে খাওয়ানো হবে)।

ভাগ্য এড়াতে আপনার সমস্ত ব্যবহারকারীদের কনফিগারেশন ফাইল বা অস্পষ্ট ডাটাবেস সারণিতে খনন করতে চান না ...


উন্মাদ একনায়ক, উন্মাদ প্রজেক্ট ম্যানেজার, উন্মাদ ক্লায়েন্ট ... পিএফএফ।
মাহদী

এটা সঠিক উত্তর!
জ্যাকবিবি 27'17

2

"আপনার" ডেটাটির পরিবর্তনের প্রয়োজন থাকতে পারে যদিও ডেটা বাস্তব জগতে প্রতিনিধিত্ব করে এমন সত্তা নাও পারে। আপনার কোনও সিদ্ধান্ত নেওয়া দরকার যে কোনও অ্যাপ্লিকেশনটি সম্পূর্ণরূপে আপডেট না করে আপডেট করা যেতে পারে এমন কোনও পৃথক টেক্সট ফাইল অন্তর্ভুক্ত করা উপযুক্ত is

উদাহরণ:

  1. টাইপোগ্রাফিক ত্রুটি / ভুল বানান।
  2. দুর্ঘটনা বাদ দেওয়া ission
  3. অন্য ভাষায় ডেটা অফার করুন।
  4. ব্যবহারকারীকে তাদের নিজস্ব পরিবর্তন করার জন্য একটি উপায় অফার করুন।

অন্য কোনও ধরণের ডেটা স্ট্রাকচার পরিবর্তনের জন্য সম্ভবত অ্যাপ্লিকেশনটির আপডেট দরকার হবে, এতে কোনও লাভ নেই।


1

আমি মূলত স্ট্যাকওভারফ্লোতে এই প্রশ্নের জন্য এই উত্তরটি লিখেছিলাম , তবে আমি মনে করি একই উত্তরটি এই প্রশ্নের ক্ষেত্রেও প্রযোজ্য।

ম্যাথিয়াস ভেরেইসের একটি নিবন্ধ রয়েছে যা এখানে আপনার সমস্যার কথা বলছে । তিনি ইউআই পরিবেশনকারী ধারণা থেকে মডেলটিতে মান অবজেক্টগুলি পৃথক করার বিষয়ে কথা বলেন।

দেশগুলি সত্তা বা মান বস্তু হিসাবে মডেল করবেন কিনা জানতে চাইলে নিবন্ধ থেকে উদ্ধৃতি দেওয়া:

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

তিনি একটি নতুন ধারণা চালু করার জন্য একটি ভিন্ন পদ্ধতির পরামর্শ দিয়েছেন AvailableCountry:

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

<?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];
    }
}

সুতরাং এটি একটি তৃতীয় সমাধান আছে যা উভয় মান বস্তু এবং সত্তা হিসাবে সারণী আপ মডেল হয়।

বিটিডাব্লিউ নিশ্চিত করে নিন যে আপনি নিবন্ধটি সম্পর্কে কিছু গুরুতর আলোচনার জন্য মন্তব্য বিভাগটি পরীক্ষা করেছেন ।


-1

বিবেচনা করার বিষয়গুলি:

  • কিভাবে স্থিতিশীল তথ্য? যদি এটি কখনই পরিবর্তিত হয় না তবে এটি বস্তুটিতে থাকা উচিত। ডেটা পরিবর্তন করার জন্য আপনাকে পুনরায় সংকলন করতে হবে এবং পুনর্নির্মাণ করতে হবে। আপনি কি সামান্য পরিবর্তনের জন্য পুনর্বাসনে খুশি?

  • যদি এটি একটি ওয়েব অ্যাপ্লিকেশন এবং এটি আপনার ওয়েবকনফাইগের অংশ হিসাবে থাকে তবে আপনি যখন সেই ডেটাতে পরিবর্তন করেন তখন আপনি অ্যাপ্লিকেশন পুনরায় চালু করতে খুশি হন?

  • যদি আপনি এটি একটি ডেটাবেজে রাখেন তবে আপনি সর্বদা এটি ক্লায়েন্ট সাইড (ডেস্কটপ অ্যাপ্লিকেশন) বা সার্ভার সাইড (পরিষেবা বা ওয়েবসাইট) এ ক্যাশে করতে পারেন। ডাটাবেস একটি ভাল সমাধান আইএমও হতে পারে।


কিভাবে স্ট্যাটিক ডাটা মন্তব্য প্রশ্নকর্তা দ্বারা উপলব্ধ করা হয়েছে সম্পর্কে শোধন: বিবেচনা "এটা রানটাইম সময় পরিবর্তন করবে না বা আরম্ভ একটি নতুন বিল্ড গ্রহণযোগ্য হবে।" সম্পাদন করা যে জন্য অ্যাকাউন্টে উত্তর ing
মশা
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.