কোডে স্ট্যাটিক ডাটাবেস ডেটা উল্লেখ করার সেরা উপায়?

Question

অনেক অ্যাপ্লিকেশনগুলিতে 'স্ট্যাটিক ডেটা' অন্তর্ভুক্ত থাকে: এমন ডেটা যা অ্যাপ্লিকেশনটির জীবদ্দশায় সত্যিকার অর্থে পরিবর্তন হয় না। উদাহরণস্বরূপ, আপনার কাছে বিক্রয় ক্ষেত্রগুলির একটি তালিকা থাকতে পারে যা সম্ভাব্য ভবিষ্যতের জন্য একটি নির্দিষ্ট তালিকা হতে পারে।

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

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

কোডে এই স্ট্যাটিক ডেটা উল্লেখ করার সর্বোত্তম উপায় কী? কেন?

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

স্ট্যাটিক ডাটাবেস ডেটা নিয়ে কাজ করার সময় আমার অন্য কোনও বিশেষ বিবেচনা করা উচিত? উদাহরণস্বরূপ, এই টেবিলগুলিকে একটি বিশেষ নাম দেওয়া?

Comments

সম্ভাব্য সদৃশ: প্রোগ্রামার্স.স্ট্যাকেক্সেঞ্জার.কম

— সেকশনস

Answer 1

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

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

Comments

ক্যাচিং অবশ্যই ভাল তবে আপনি এই মানগুলি কীভাবে আপডেট করবেন? সম্ভবত একটি অ্যাপ্লিকেশন পুনরায় চালু হবে, বা ক্যাশে অবৈধ কৌশল কোনও ধরণের?

— স্টিভ

@ স্টিভ হ্যাঁ, ঠিক আবেদনের উপর নির্ভর করে। কোনও কিছু ঘন ঘন শুরু করার জন্য পুনঃসূচনাটি ভাল। দীর্ঘ চলমান অ্যাপ্লিকেশনটির জন্য, সম্ভবত ধীর সময়ে দিনে একবার ক্যাশে পুনরায় লোড করা হচ্ছে। আমার প্রশ্নটি হবে, এমন একটি পরিস্থিতি সম্পর্কে যেখানে অ্যাপ্লিকেশনটি খুব স্বল্পকালীন জীবনযাপন চালায়। পছন্দ করুন, সম্ভবত কোনও পিএইচপি স্ক্রিপ্ট বা কিছু সাদৃশ্য।

— টাইলারম্যাক

ডেটাবেসটি ঘন ঘন অ্যাক্সেস করা ডেটার জন্য নিজস্ব ক্যাশে চালাবে যাতে আপনি ইতিমধ্যে বাস্তবায়িত এমন কোনও কিছু পুনরায় বাস্তবায়ন করবেন (এবং সম্ভবত এটিও নয়!)

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

@JamesAnderson: আবেদন মানে ক্যাশে সেখানে মাত্র করবে কি কখনো ডাটাবেসের সাথে এক কল করা। হ্যাঁ, ডাটাবেসগুলির নিজস্ব ক্যাশে থাকবে তবে সেগুলি আপনার অ্যাপ্লিকেশনের নিয়ন্ত্রণের বাইরে থাকা ইভেন্টগুলি দ্বারা অবৈধ / রিফ্রেশ হতে পারে এবং আপনাকে এখনও ডাটাবেসের সাথে সংযোগ রাখতে হবে এবং সেই ডেটা পেতে একটি কোয়েরি করতে হবে (এবং আশা করি এটি এতে রয়েছে ডিবি এর ক্যাশে)। কোনও সাধারণ ইন-অ্যাপ্লিকেশন ক্যাশে প্রয়োগ করা সত্যিই এতটা কঠিন নয়।

— হতাশ

Answer 2

ডিবি বা হার্ড কোডিংয়ের বিকল্প হ'ল প্রারম্ভকালে পড়া কনফিগার ফাইল ব্যবহার করা। তারপরে আপনি এই কোডটি আপনার কোডের মধ্যে কেবল পঠনযোগ্য কাঠামোর মধ্যে সঞ্চয় করতে পারেন।

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

Comments

কিছু ধরণের স্ট্যাটিক ডেটার জন্য ভাল ধারণা, তবে আপনি যদি প্রশ্নে বর্ণিত FK সম্পর্ক প্রয়োগ করতে চান তবে এতটা ভাল নয়।

— ক্রমিই পুনর্নির্মাণ মনিকা

প্রশ্ন এটি একটি প্রয়োজন ছিল না, শুধুমাত্র একটি দৃশ্য। যদি এটির প্রয়োজন না হয় তবে কনফিগার ফাইলের পদ্ধতি ভালভাবে কাজ করে।

— স্টিভ

আপনি ঠিক বলেছেন, আমি যথেষ্ট পরিষ্কার ছিল না। তবে আমি সন্তুষ্ট ... কারণ আপনার উত্তর থেকে আমি কিছু শিখেছি। আমি এই পদ্ধতির আগে কখনও আসেনি।

— ক্রমিই পুনর্নির্মাণ মনিকা

Answer 3

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

প্রায়শই আমরা যা স্থির করব বলে মনে হয় তা না হয়ে যায় এবং যখন এটি ঘটে তখন আপনাকে কোনও পরিবর্তন প্রকাশের জন্য কোনও কোড প্রকাশের জন্য অপেক্ষা করতে হবে না। যত তাড়াতাড়ি এটি ঘটে যায়, এটি ডাটাবেসে রাখুন এবং আরও আপডেট করার জন্য প্রশাসক পৃষ্ঠা লিখুন।

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

Comments

"প্রায়শই আমরা যা স্থির করব বলে মনে হয় তা না হয়ে দেখা দেয়" - তাই সত্য।

— ক্রমিই পুনর্নির্মাণ মনিকা

Answer 4

কেন শুধু হার্ড কোড সব কিছু নয়? আমার সর্বদা প্রধান সমস্যাটি হ'ল অ্যাপ্লিকেশন কোডে ডিবি থেকে স্থির মানগুলি উল্লেখ করা । আপনি যদি সরাসরি ড্রপ-ডাউন তালিকা বা স্থির মানগুলির বাইরে কিছু তৈরি করেন তবে এটি একটি জিনিস, তবে যদি কিছু অ্যাপ্লিকেশন যুক্তি ডিবি থেকে প্রাপ্ত মানগুলির উপর নির্ভর করে?

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

বিষয়বস্তু আইটেমগুলিতে তারা কোন অবস্থানে রয়েছে তার উপর নির্ভর করে আলাদাভাবে চিকিত্সা করা উচিত I আমি যদি এই স্টেটের ডেটা যথাক্রমে 1, 2, 3 এর মান ডিবিতে রাখি, তবে আমি কীভাবে কিছু খসড়াতে যাচাই করব? অবস্থা?

if (content.State == 1)
বা
if (content.State == "Draft")?

আমি সবেমাত্র মানগুলি কোড করে ফেলেছি!
আপনি যদি ক্যাশে / হ্যাশ টেবিল ব্যবহার করেন তবে একই জিনিস: আপনার ডেটা সন্ধানের জন্য আপনাকে এখনও কোডে লিখিত কিছু মান ব্যবহার করতে হবে।

হার্ড-কোডিং এপ্রোচগুলির অসুবিধাগুলি কী কী?

Comments

অসুবিধাটি যেমন পিডিআর বলেছেন, "প্রায়শই আমরা যা স্থির করব বলে মনে হয় তা না হয়ে যায়"।

— টাইলারম্যাক

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

— ডেভ

Answer 5

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

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

Comments

একবার এবং কেবল একবারের জন্য +1। কিন্তু বিভিন্ন সারি আলাদাভাবে চিকিত্সা সম্পর্কে কি?

— ক্রমিই পুনর্নির্মাণ মনিকা

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

— স্কট হুইটলক

Answer 6

এটি এর খারাপ সময়ে অকাল অপ্টিমাইজেশন।

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

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

এখানে যাওয়ার দুটি উপায় রয়েছে: -

এটি একটি ডাটাবেসে সংরক্ষণ করুন এবং "স্বাভাবিক" বর্গক্ষেত্রের সাথে ডেটা অ্যাক্সেস করুন।

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

Answer 7

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

Answer 8

আমি জানি এই উত্তরটি গৃহীত হয়েছিল তবে আমি আমাদের শেষ ওয়েব বিকাশের দোকানে যেখানে এটি সম্ভব সেখানে ভাগ করে নিতে চেয়েছিলাম যেখানে আমরা যতটা সম্ভব ডাটাবেস I / O হ্রাস করার চেষ্টা করেছি।

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

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

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

Answer 9

এটির জন্য আমার সমাধান, যা সমস্ত পরিস্থিতিতে নাও কার্যকর হতে পারে, তা হ'ল স্থির ডাটাবেস ডেটা একটি হার্ড কোডিংয়ের সাথে আবদ্ধ করা enum। যেহেতু সমস্যা গতিশীল তথ্য (ডাটাবেস) স্ট্যাটিক যুক্তিবিজ্ঞান (কোড) আবদ্ধ থাকার থেকে আসে, মেক এই বাঁধাই স্পষ্ট (এবং আলগা) যে সহযোগীদের একটি ডাটাবেস টেবিল থাকার enum। উদা:

LooseDBCodeBinding (database table)
   ID : Int32 (key)
   Name : String
   HardCodedTypeID : Int32

// in code:
public enum LooseDBCodeBinding
{
   TYPE_1 = 1,
   TYPE_2 = 2,
   TYPE_3 = 3 // etc...
}

তারপরে একটি ইউআই লিখুন যা আপনাকে LooseDBCodeBindingরেকর্ডগুলির তালিকা সহজেই দেখতে দেয় এবং LooseDBCodeBinding enumমানগুলিতে ম্যাপ করে ("ভাঙা" বাইন্ডিং সমর্থন সহ) supporting এরপরে আপনি চারপাশে প্রোগ্রাম করতে পারেন enumএবং টেবিল কীটির চারপাশে ডাটাবেসটি ডিজাইন করতে পারেন এবং এটি কেবলমাত্র এই টেবিলটিতে উভয় প্রসঙ্গে জ্ঞান থাকতে পারে।