অ্যাপ্লিকেশন বিকাশকারীদের দ্বারা সাধারণ ডাটাবেস বিকাশের ভুলগুলি কী কী?
প্রায় সদৃশ stackoverflow.com/questions/346659/...
—
dkretz
অ্যাপ্লিকেশন বিকাশকারীদের দ্বারা সাধারণ ডাটাবেস বিকাশের ভুলগুলি কী কী?
উত্তর:
1. যথাযথ সূচক ব্যবহার না করা
এটি তুলনামূলকভাবে সহজ তবে এখনও এটি সর্বদা ঘটে। বিদেশী কীগুলির উপর তাদের সূচি থাকতে হবে। আপনি যদি কোনও ক্ষেত্রে কোনও ক্ষেত্র ব্যবহার করছেন তবে আপনার WHEREসম্ভবত এটির একটি সূচক থাকা উচিত। এই জাতীয় সূচকগুলি প্রায়শই আপনাকে সম্পাদন করতে হবে এমন প্রশ্নের উপর ভিত্তি করে একাধিক কলাম কভার করা উচিত।
2. রেফারেন্সিয়াল অখণ্ডতা প্রয়োগ না
আপনার ডাটাবেসটি এখানে পরিবর্তিত হতে পারে তবে যদি আপনার ডাটাবেসগুলি রেফারেনশিয়াল অখণ্ডতা সমর্থন করে - যার অর্থ সমস্ত বিদেশী কীগুলি বিদ্যমান যে সত্তার দিকে নির্দেশ করার গ্যারান্টিযুক্ত - আপনি এটি ব্যবহার করা উচিত।
মাইএসকিউএল ডাটাবেসে এই ব্যর্থতাটি দেখতে বেশ সাধারণ বিষয়। আমি বিশ্বাস করি না যে মাইআইএসএএম এটি সমর্থন করে। ইনোডিবি করে। আপনি মাইআইএসএএম ব্যবহার করছেন এমন ব্যক্তি বা যারা ইনোডিবি ব্যবহার করছেন তবে যে কোনওভাবেই এটি ব্যবহার করছেন না তাদের আপনি খুঁজে পাবেন।
আরও এখানে:
৩. সারোগেট (প্রযুক্তিগত) প্রাথমিক কীগুলির চেয়ে প্রাকৃতিক ব্যবহার
প্রাকৃতিক কীগুলি হ'ল বহিরাগত অর্থবহ ডেটার উপর ভিত্তি করে এমন চাবি যা (বাহ্যভাবে) অনন্য। সাধারণ উদাহরণগুলি হ'ল পণ্য কোডগুলি, দ্বি-বর্ণের রাষ্ট্রীয় কোডগুলি (মার্কিন), সামাজিক সুরক্ষা নম্বরগুলি এবং এগুলি। সারোগেট বা প্রযুক্তিগত প্রাথমিক কীগুলি হ'ল সিস্টেমের বাইরে একেবারেই কোনও অর্থ নেই। এগুলি সত্তা সনাক্তকরণের জন্য বিশুদ্ধভাবে উদ্ভাবিত এবং সাধারণত স্বতঃবৃদ্ধি ক্ষেত্র (এসকিউএল সার্ভার, মাইএসকিউএল, অন্যান্য) বা সিকোয়েন্সগুলি (সর্বাধিক উল্লেখযোগ্য ওরাকল)।
আমার মতে আপনার সর্বদা সারোগেট কীগুলি ব্যবহার করা উচিত । এই প্রশ্নগুলিতে এই প্রশ্নগুলি উঠে এসেছে:
এটি কিছুটা বিতর্কিত বিষয়, যার উপরে আপনি সর্বজনীন চুক্তি পাবেন না। আপনি কিছু লোককে পেতে পারেন, যারা প্রাকৃতিক কীগুলি কিছু পরিস্থিতিতে ঠিক আছে বলে মনে করেন, তর্কাতীতভাবে অপ্রয়োজনীয় হওয়া ছাড়া আপনি সার্গেট কীগুলি নিয়ে কোনও সমালোচনা পাবেন না। আপনি যদি আমাকে জিজ্ঞাসা করেন তবে এটি বেশ ছোট্ট একটি খারাপ দিক।
মনে রাখবেন, এমনকি দেশগুলিও অস্তিত্ব বন্ধ করতে পারে (উদাহরণস্বরূপ, যুগোস্লাভিয়া)।
4. DISTINCTকাজ করা প্রয়োজন যে কোয়েরি লিখছেন
আপনি প্রায়শই এটি ওআরএম-উত্পন্ন উত্সগুলি দেখুন see হাইবারনেট থেকে লগ আউটপুটটি দেখুন এবং আপনি সমস্ত ক্যোয়ারী দিয়ে শুরু দেখতে পাবেন:
SELECT DISTINCT ...
আপনি সদৃশ সারিগুলি ফেরত পাবেন না এবং যাতে সদৃশ বস্তুগুলি না পায় তা নিশ্চিত করার জন্য এটি একটি শর্টকাট bit আপনি কখনও কখনও লোকেরা এটিও করতে দেখবেন। আপনি যদি এটি খুব বেশি দেখেন তবে এটি একটি সত্যিকারের লাল পতাকা। এমন নয় যে DISTINCTখারাপ অথবা বৈধ অ্যাপ্লিকেশন নেই। এটি (উভয় বিবেচনায়) রয়েছে তবে সঠিক অনুসন্ধানগুলি লেখার জন্য এটি কোনও সার্গেট বা স্টপগ্যাপ নয়।
থেকে কেন আমি স্বতন্ত্র ঘৃণা :
আমার মতামত অনুসারে জিনিসগুলি সর্বাগ্রে পরিণত হয় যখন কোনও বিকাশকারী যখন যথেষ্ট তদন্ত করে, একসাথে সারণীগুলিতে যোগ দেয় এবং হঠাৎ করেই বুঝতে পারে যে দেখে মনে হয় যে সে নকল (বা আরও বেশি) সারি এবং তার তাত্ক্ষণিক প্রতিক্রিয়া পাচ্ছে ... এই "সমস্যার" তার "সমাধান" হ'ল DISTINCT কীওয়ার্ডটি ছুঁড়ে ফেলা এবং তার সমস্ত ঝামেলা দূরে যায় P
5. যোগদানের উপর একীকরণ পছন্দসই
ডেটাবেস অ্যাপ্লিকেশন বিকাশকারীদের দ্বারা আর একটি সাধারণ ভুল হ'ল উপলব্ধি করা না যে আরও বেশি ব্যয়বহুল সমষ্টি (যেমন GROUP BYক্লজ) যোগদানের সাথে তুলনা করা যায়।
এটি কতটা বিস্তৃত তা সম্পর্কে আপনাকে ধারণা দেওয়ার জন্য, আমি এই বিষয়টিতে এখানে বেশ কয়েকবার লিখেছি এবং এর জন্য অনেকটা নিম্নচালিত হয়েছি। উদাহরণ স্বরূপ:
এসকিউএল বিবৃতি থেকে - "যোগদান" বনাম "গ্রুপ দ্বারা এবং থাকা" :
প্রথম জিজ্ঞাসা:
SELECT userid FROM userrole WHERE roleid IN (1, 2, 3) GROUP by userid HAVING COUNT(1) = 3প্রশ্নের সময়: 0.312 এস
দ্বিতীয় প্রশ্ন:
SELECT t1.userid FROM userrole t1 JOIN userrole t2 ON t1.userid = t2.userid AND t2.roleid = 2 JOIN userrole t3 ON t2.userid = t3.userid AND t3.roleid = 3 AND t1.roleid = 1প্রশ্নের সময়: 0.016 এস
সেটা ঠিক. আমি প্রস্তাবিত যোগদানের সংস্করণটি সামগ্রিক সংস্করণের চেয়ে বিশ গুণ দ্রুত।
Complex. ভিউগুলির মাধ্যমে জটিল প্রশ্নগুলি সরলকরণ নয়
সমস্ত ডাটাবেস বিক্রেতারা মতামতকে সমর্থন করে না তবে যাঁরা করেন তাদের পক্ষে, যদি বিচারিকভাবে ব্যবহার করা হয় তবে তারা অনুসন্ধানগুলি ব্যাপকভাবে সরল করতে পারে। উদাহরণস্বরূপ, একটি প্রকল্পে আমি সিআরএম-এর জন্য জেনেরিক পার্টি মডেল ব্যবহার করেছি। এটি একটি অত্যন্ত শক্তিশালী এবং নমনীয় মডেলিং কৌশল তবে অনেকগুলিতে যোগ দিতে পারে। এই মডেলটিতে ছিল:
উদাহরণ:
সুতরাং টেডকে তার নিয়োগকর্তার সাথে সংযুক্ত করতে পাঁচটি টেবিল যুক্ত হয়েছে। আপনি ধরে নিলেন সমস্ত কর্মচারী ব্যক্তি (সংস্থা নয়) এবং এই সহায়তা দর্শন সরবরাহ করুন:
CREATE VIEW vw_employee AS
SELECT p.title, p.given_names, p.surname, p.date_of_birth, p2.party_name employer_name
FROM person p
JOIN party py ON py.id = p.id
JOIN party_role child ON p.id = child.party_id
JOIN party_role_relationship prr ON child.id = prr.child_id AND prr.type = 'EMPLOYMENT'
JOIN party_role parent ON parent.id = prr.parent_id = parent.id
JOIN party p2 ON parent.party_id = p2.id
এবং হঠাৎ আপনার কাছে থাকা ডেটাগুলির একটি খুব সাধারণ দৃশ্য রয়েছে তবে একটি অত্যন্ত নমনীয় ডেটা মডেল।
San. স্যানিটাইজিং ইনপুট নয়
এটি একটি বিশাল এক। এখন আমি পিএইচপি পছন্দ করি তবে আপনি কী করছেন তা যদি আপনি না জানেন তবে আক্রমণ করার ঝুঁকিপূর্ণ সাইটগুলি তৈরি করা সত্যিই সহজ। ছোট্ট ববি টেবিলগুলির গল্পের চেয়ে ভাল আর কোনও কিছুই এটির পক্ষে যোগ করে না ।
ইউআরএল, ফর্ম ডেটা এবং কুকিজের মাধ্যমে ব্যবহারকারী দ্বারা সরবরাহ করা ডেটা সর্বদা প্রতিকূল এবং স্যানিটাইজড হিসাবে বিবেচনা করা উচিত। আপনি যা আশা করছেন তা পেয়ে যাচ্ছেন তা নিশ্চিত করুন।
8. প্রস্তুত বিবৃতি ব্যবহার না
প্রস্তুত বিবৃতিগুলি হ'ল আপনি যখন সন্নিবেশ, আপডেট এবং WHEREধারাগুলিতে ব্যবহৃত কোনও ডেটা সংকলন করেন এবং পরে সরবরাহ করেন। উদাহরণ স্বরূপ:
SELECT * FROM users WHERE username = 'bob'
বনাম
SELECT * FROM users WHERE username = ?
অথবা
SELECT * FROM users WHERE username = :username
আপনার প্ল্যাটফর্মের উপর নির্ভর করে
আমি এটি করে ডাটাবেসগুলি তাদের হাঁটুর কাছে নিয়ে এসেছি। মূলত, প্রতিটি সময় কোনও আধুনিক ডাটাবেস একটি নতুন ক্যোয়ারির মুখোমুখি হয় এটি এটি সংকলন করতে হয়। এটি যদি এর আগে দেখা কোনও প্রশ্নের মুখোমুখি হয় তবে আপনি ডাটাবেসটিকে সংকলিত ক্যোয়ারী এবং সম্পাদন পরিকল্পনাটি ক্যাশে দেওয়ার সুযোগ দিচ্ছেন opportunity কোয়েরিটি অনেকটা করে আপনি ডাটাবেসকে সেই চিত্রটি বের করার এবং সে অনুযায়ী অনুকূলকরণের সুযোগ দিচ্ছেন (উদাহরণস্বরূপ, মেমরিতে সংকলিত ক্যোয়ারীটি পিন করে)।
প্রস্তুত বিবৃতি ব্যবহার করে আপনাকে কতগুলি নির্দিষ্ট প্রশ্ন ব্যবহৃত হয় সে সম্পর্কে অর্থবহ পরিসংখ্যানও দেবে।
প্রস্তুত বিবৃতিগুলি এসকিউএল ইঞ্জেকশন আক্রমণগুলির থেকে আপনাকে আরও রক্ষা করবে।
9. যথেষ্ট স্বাভাবিক না
ডাটাবেস নরমালাইজেশন মূলত ডাটাবেস ডিজাইনের অনুকূলকরণের প্রক্রিয়া বা কীভাবে আপনি আপনার ডেটা টেবিলগুলিতে সংগঠিত করেন।
এই সপ্তাহে আমি এমন কিছু কোড জুড়ে দৌড়েছি যেখানে কেউ একটি অ্যারে চাপিয়ে দিয়েছিল এবং এটি একটি ডাটাবেসে একটি একক ক্ষেত্রে intoুকিয়েছে। এটি স্বাভাবিক করা হ'ল এই অ্যারের উপাদানটিকে শিশু টেবিলে একটি পৃথক সারি হিসাবে বিবেচনা করা হবে (অর্থাত্ একটি একাধিক সম্পর্ক)।
এটি ব্যবহারকারী আইডির একটি তালিকা সংরক্ষণের জন্য সেরা পদ্ধতিতেও এসেছে :
আমি অন্যান্য সিস্টেমে দেখেছি যে তালিকাটি সিরিয়ালযুক্ত পিএইচপি অ্যারেতে সংরক্ষিত আছে।
তবে স্বাভাবিককরণের অভাব বিভিন্ন রূপে আসে।
আরও:
১০. খুব বেশি সাধারণকরণ
এটি পূর্ববর্তী পয়েন্টের সাথে দ্বন্দ্বের মতো বলে মনে হতে পারে তবে অনেকগুলি জিনিসের মতো স্বাভাবিককরণও একটি সরঞ্জাম। এটি একটি শেষের উপায় এবং নিজের এবং নিজেই শেষ নয়। আমি মনে করি অনেক বিকাশকারী এটি ভুলে যায় এবং একটি "অর্থ" হিসাবে "শেষ" হিসাবে চিকিত্সা শুরু করে। ইউনিট টেস্টিং এটির একটি প্রধান উদাহরণ।
আমি একবার এমন সিস্টেমে কাজ করেছি যার ক্লায়েন্টদের জন্য এমন একটি বিশাল স্তরক্রম ছিল যা এরকম কিছু হয়েছিল:
Licensee -> Dealer Group -> Company -> Practice -> ...
যেমন কোনও অর্থবহ ডেটা পাওয়ার আগে আপনাকে প্রায় 11 টি টেবিল একসাথে যোগ দিতে হয়েছিল। এটি খুব বেশি দূরে নেওয়া সাধারণকরণের একটি ভাল উদাহরণ was
আরও উল্লেখযোগ্য বিষয় হল, সাবধানে এবং বিবেচিত ডেনারমালাইজেশনের বিশাল কার্যকারিতা সুবিধা থাকতে পারে তবে এটি করার সময় আপনাকে অবশ্যই সতর্কতা অবলম্বন করতে হবে।
আরও:
১১. একচেটিয়া আরাকস ব্যবহার করা
একটি এক্সক্লুসিভ আর্ক একটি সাধারণ ভুল যেখানে দুটি বা ততোধিক বিদেশী কী দিয়ে একটি টেবিল তৈরি করা হয় যেখানে তাদের মধ্যে কেবলমাত্র একটিই শূন্য হতে পারে। বড় ভুল. একটি জিনিসের জন্য এটি ডেটা অখণ্ডতা বজায় রাখা এত কঠিন হয়ে ওঠে। সর্বোপরি, এমনকি রেফারেন্সিয়াল অখণ্ডতা থাকা সত্ত্বেও, এই বিদেশী কীগুলির দুটি বা তার বেশি স্থাপন করা বাধা দেয় না (জটিল চেক সীমাবদ্ধতা সত্ত্বেও)।
থেকে রিলেশনাল ডাটাবেস ডিজাইন করতে প্র্যাকটিকাল গাইড :
আমরা যেখানেই সম্ভব সেখানে একচেটিয়া তোরণ নির্মাণের বিরুদ্ধে দৃ strongly়ভাবে পরামর্শ দিয়েছি, উপযুক্ত কারণেই তারা কোড লিখতে অসুবিধায় থাকতে পারে এবং আরও রক্ষণাবেক্ষণের অসুবিধা সৃষ্টি করতে পারে।
12. মোটেই প্রশ্নের উপর পারফরম্যান্স বিশ্লেষণ না করা
বাস্তববাদ বিশেষত ডাটাবেস জগতে সর্বোচ্চ শাসন করে। যদি আপনি নীতিগুলি এটিকে দৃ .়ভাবে স্থির করেন যে তারা কৌতূহল হয়ে উঠেছে তবে আপনি সম্ভবত ভুল করেছেন। উপরে থেকে সামগ্রিক প্রশ্নের উদাহরণ নিন। সমষ্টিগত সংস্করণটি "দুর্দান্ত" লাগতে পারে তবে এর অভিনয়টি খারাপ। একটি পারফরম্যান্স তুলনা তর্ক বিতর্ক শেষ করা উচিত (তবে এটি হয়নি) তবে আরও উল্লেখযোগ্য বিষয়: প্রথমদিকে এই জাতীয় অসতর্কিত দৃষ্টিভঙ্গি স্পট করা অজ্ঞতা, এমনকি বিপজ্জনক।
১৩. ইউনিয়ন সমস্ত এবং বিশেষত ইউনিয়ন গঠনের উপর অতিরিক্ত নির্ভরতা
এসকিউএল পদগুলিতে একটি ইউনিয়ন কেবল একত্রিত ডেটা সেটগুলিকে বোঝায়, যার অর্থ তাদের একই ধরণের এবং কলামগুলির সংখ্যা রয়েছে। তাদের মধ্যে পার্থক্যটি হ'ল ইউনিয়ন সমস্তই একটি সাধারণ কনটেন্টেশন এবং যেখানেই সম্ভব সেখানে অগ্রাধিকার দেওয়া উচিত যেখানে একটি ইউনিয়ন ডুপ্লিকেট টিপলস অপসারণের জন্য স্পষ্টতই একটি DISTINCT করবে।
DISTINCT এর মতো ইউনিয়নগুলিরও তাদের জায়গা রয়েছে। বৈধ অ্যাপ্লিকেশন আছে। তবে আপনি যদি নিজেকে এগুলি প্রচুর পরিমাণে করে বিশেষত সাবকোয়্যারিতে করে দেখেন তবে আপনি সম্ভবত কিছু ভুল করছেন। এটি দুর্বল ক্যোয়ারী নির্মাণের ক্ষেত্রে বা একটি খারাপ ডিজাইনের ডেটা মডেল হতে পারে যা আপনাকে এই ধরনের কাজ করতে বাধ্য করে।
ইউনিয়নগুলি, বিশেষত যখন যোগ দেয় বা নির্ভরশীল সাবকোয়রিতে ব্যবহৃত হয়, তখন একটি ডেটাবেস পঙ্গু করতে পারে। যখনই সম্ভব এগুলি এড়াতে চেষ্টা করুন।
14. প্রশ্নগুলিতে ওআর শর্তাদি ব্যবহার করে
এটি নিরীহ বলে মনে হতে পারে। সর্বোপরি, এ্যান্ডস ঠিক আছে। নাকি খুব ঠিক আছে? ভুল। মূলত একটি ও শর্তটি ডেটা সেটকে সীমাবদ্ধ করে যেখানে একটি ওআর শর্ত এটি বাড়ায় কিন্তু এমনভাবে নয় যে নিজেকে অপ্টিমাইজেশনে ndsণ দেয়। বিশেষত যখন বিভিন্ন ওআর শর্তগুলি ছেদ করতে পারে তখন ফলস্বরূপ অপছন্দকারীটিকে কার্যকরভাবে একটি DISTINCT অপারেশনে জোর করে।
খারাপ:
... WHERE a = 2 OR a = 5 OR a = 11
উত্তম:
... WHERE a IN (2, 5, 11)
এখন আপনার এসকিউএল অপ্টিমাইজার কার্যকরভাবে প্রথম ক্যোয়ারিকে দ্বিতীয়টিতে রূপান্তর করতে পারে। তবে তা নাও পারে। শুধু এটা করবেন না।
15. উচ্চ-সম্পাদনযোগ্য সমাধানগুলিতে নিজেকে ndণ দেওয়ার জন্য তাদের ডেটা মডেলটি ডিজাইন করা নয়
এটি পরিমিত করার জন্য একটি হার্ড পয়েন্ট। এটি সাধারণত এর প্রভাব দ্বারা পর্যবেক্ষণ করা হয়। আপনি যদি নিজেকে তুলনামূলক সহজ কাজগুলির জন্য উদ্ভট প্রশ্নগুলি লিখছেন বা অপেক্ষাকৃত সহজবোধ্য তথ্যের সন্ধানের জন্য প্রশ্নগুলি দক্ষ নয়, তবে আপনার কাছে সম্ভবত একটি ডেটা মডেল রয়েছে।
কিছু উপায়ে এই পয়েন্টটি পূর্বের সমস্তগুলি সংক্ষিপ্তসার করে তবে এটি একটি সতর্কতামূলক গল্পের বেশি যে কোয়েরি অপ্টিমাইজেশানের মতো কাজগুলি প্রায়শই প্রথম করা হয় যখন এটি দ্বিতীয় করা উচিত। প্রথম এবং সর্বাগ্রে আপনার অবশ্যই পারফরম্যান্সটি অনুকূল করার চেষ্টা করার আগে একটি ভাল ডেটা মডেল রয়েছে। যেমন নুথ বলেছিলেন:
অকালীন অপটিমাইজেশন হ'ল সমস্ত অশুভের মূল
16. ডাটাবেস লেনদেনের ভুল ব্যবহার
একটি নির্দিষ্ট প্রক্রিয়াটির জন্য সমস্ত ডেটা পরিবর্তনগুলি পারমাণবিক হওয়া উচিত। অর্থাৎ যদি অপারেশন সফল হয় তবে এটি পুরোপুরি করে। যদি এটি ব্যর্থ হয় তবে ডেটাটি অপরিবর্তিত রয়েছে। - 'আধাপূর্ণ' পরিবর্তনের কোনও সম্ভাবনা থাকা উচিত নয়।
আদর্শভাবে, এটি অর্জনের সহজতম উপায় হ'ল সম্পূর্ণ সিস্টেম ডিজাইনের একক INSERT / আপডেট / ডিলিট স্টেটমেন্টের মাধ্যমে সমস্ত ডেটা পরিবর্তনগুলিকে সমর্থন করার জন্য প্রচেষ্টা করা উচিত। এই ক্ষেত্রে, কোনও বিশেষ লেনদেন পরিচালনার প্রয়োজন নেই, কারণ আপনার ডাটাবেস ইঞ্জিনটি স্বয়ংক্রিয়ভাবে এটি করা উচিত।
যাইহোক, যদি কোনও প্রক্রিয়াটির প্রয়োজন হয় যাতে একচেটিয়া অবস্থায় তথ্য রাখতে একক হিসাবে একাধিক বিবৃতি দেওয়া হয়, তবে উপযুক্ত লেনদেন নিয়ন্ত্রণ প্রয়োজন।
আপনার ডাটাবেস সংযোগ স্তর এবং ডাটাবেস ইঞ্জিন কীভাবে এই ক্ষেত্রে ইন্টারঅ্যাক্ট করে তার সাবটলটিগুলিতে সাবধানতার সাথে মনোযোগ দেওয়ার পরামর্শ দেওয়া হয়েছে।
17. 'সেট-ভিত্তিক' দৃষ্টান্ত বোঝা হচ্ছে না
এসকিউএল ভাষা নির্দিষ্ট ধরণের সমস্যার জন্য উপযুক্ত একটি নির্দিষ্ট দৃষ্টান্ত অনুসরণ করে। জাভা, সি #, ডেলফি ইত্যাদির মতো ল্যাঙ্গুয়েজে ন্যূনতম সমস্যাগুলির সাথে মোকাবিলার জন্য ভাষা সংগ্রাম করে বিভিন্ন বিক্রেতার সাথে নির্দিষ্ট এক্সটেনশন ith
এই বোঝার অভাবটি নিজেকে কয়েকভাবে প্রকাশ করে।
দায়িত্বের স্পষ্ট বিভাজন নির্ধারণ করুন এবং প্রতিটি সমস্যা সমাধানের জন্য উপযুক্ত সরঞ্জামটি ব্যবহার করার চেষ্টা করুন।
বিকাশকারীদের দ্বারা তৈরি মূল ডেটাবেস ডিজাইন এবং প্রোগ্রামিং ভুল
স্বার্থপর ডাটাবেস ডিজাইন এবং ব্যবহার। ডেভেলপাররা প্রায়শই ডেটাবেসটিকে ডেটাতে অন্যান্য স্টেকহোল্ডারদের প্রয়োজন বিবেচনা না করে তাদের ব্যক্তিগত ধ্রুবক স্টোর স্টোর হিসাবে বিবেচনা করে। এটি প্রয়োগ স্থপতিদের ক্ষেত্রেও প্রযোজ্য। ডেটাবেস ডিজাইন এবং ডেটা অখণ্ডতা তৃতীয় পক্ষের ডেটা নিয়ে কাজ করা কঠিন করে তোলে এবং সিস্টেমের জীবনচক্রের ব্যয়কে যথেষ্ট পরিমাণে বাড়িয়ে তুলতে পারে। রিপোর্টিং এবং এমআইএস অ্যাপ্লিকেশন ডিজাইনে একটি দরিদ্র চাচাতো বোন হয়ে থাকে এবং কেবল একটি চিন্তাভাবনা হিসাবে সম্পন্ন হয়।
অস্বীকৃতিযুক্ত ডেটা ব্যবহার করা হচ্ছে। অতিমাত্রায় অস্বীকৃত ডেটা এবং প্রয়োগের মধ্যে এটিকে বজায় রাখার চেষ্টা করা ডেটা অখণ্ডতার সমস্যাগুলির একটি রেসিপি। স্বল্প পরিমাণে অস্বীকৃতি ব্যবহার করুন। কোনও ক্যোয়ারিতে একটি যোগ যোগ করতে না চাওয়া হ'ল অস্বীকার করার অজুহাত নয়।
এসকিউএল লিখে ভয় পেয়েছি। এসকিউএল রকেট বিজ্ঞান নয় এবং এটি কার্য সম্পাদনে আসলে বেশ ভাল। ও / আর ম্যাপিং স্তরগুলি 95% ক্যোরিয়াস করা বেশ ভাল যা সাধারণ এবং সেই মডেলটিতে ভাল ফিট। কখনও কখনও এসকিউএল হয় কাজ করার সেরা উপায়।
কৌতুকপূর্ণ 'কোনও সঞ্চিত পদ্ধতি নয়' নীতি। আপনি বিশ্বাস করেন যে সঞ্চিত পদ্ধতিগুলি খারাপ কিনা, এই সফ্টওয়্যার প্রকল্পে এই ধরণের মতবাদী মনোভাবের কোনও স্থান নেই।
ডাটাবেস ডিজাইন বুঝতে পারছি না। সাধারণীকরণটি আপনার বন্ধু এবং এটি রকেট বিজ্ঞান নয়। যোগদান এবং কার্ডিনালিটি মোটামুটি সহজ ধারণা - আপনি যদি ডেটাবেস অ্যাপ্লিকেশন বিকাশের সাথে জড়িত থাকেন তবে সেগুলি না বোঝার জন্য আসলেই কোনও অজুহাত নেই।
অতিরিক্ত ব্যবহার এবং / অথবা সঞ্চিত পদ্ধতিতে নির্ভরতা।
কিছু অ্যাপ্লিকেশন বিকাশকারী সঞ্চিত পদ্ধতিগুলি মিডল টায়ার / ফ্রন্ট এন্ড কোডের সরাসরি সম্প্রসারণ হিসাবে দেখেন see এটি মাইক্রোসফ্ট স্ট্যাক বিকাশকারীদের একটি সাধারণ বৈশিষ্ট্য বলে মনে হয়, (আমি একজন, তবে আমি এটি থেকে বেরিয়ে এসেছি) এবং অনেকগুলি সঞ্চিত প্রক্রিয়া তৈরি করে যা জটিল ব্যবসায়িক যুক্তি এবং ওয়ার্কফ্লো প্রক্রিয়াকরণ সম্পাদন করে। এটি আরও কোথাও ভাল করা হয়।
সঞ্চিত প্রক্রিয়াগুলি কার্যকর যেখানে এটি সত্যই প্রমাণিত হয়েছে যে কিছু প্রকৃত প্রযুক্তিগত উপাদান তাদের ব্যবহারের প্রয়োজন হয় (উদাহরণস্বরূপ, কার্য সম্পাদন এবং সুরক্ষা) উদাহরণস্বরূপ, বৃহত ডেটা সেটগুলিকে একত্রিত করা / ফিল্টারিং রাখা "ডেটার নিকটে"।
আমাকে সম্প্রতি একটি বিশাল ডেলফি ডেস্কটপ অ্যাপ্লিকেশন বজায় রাখতে এবং উন্নত করতে সহায়তা করতে হয়েছিল যার মধ্যে 1400 এসকিউএল সার্ভার স্টোরেজ পদ্ধতিতে (ইউআই ইভেন্ট হ্যান্ডলারের অবশিষ্ট অংশ) ব্যবসায়িক যুক্তি এবং নিয়মগুলির 70% প্রয়োগ করা হয়েছিল। এটি একটি দুঃস্বপ্ন ছিল, মূলত টিএসকিউএলে কার্যকর ইউনিট পরীক্ষার প্রবর্তন, এনক্যাপসুলেশনের অভাব এবং দুর্বল সরঞ্জামগুলির (ডিবাগার, সম্পাদক) অভাবের কারণে।
অতীতে জাভা দলের সাথে কাজ করা আমি দ্রুত জানতে পারি যে প্রায়শই সম্পূর্ণ বিপরীত পরিবেশটি সেই পরিবেশে ধারণ করে। একটি জাভা আর্কিটেক্ট একবার আমাকে বলেছিল: "ডাটাবেস কোডের জন্য নয়, ডেটার জন্য" "
আজকাল আমি মনে করি এটি সঞ্চিত প্রকল্পগুলি মোটেও বিবেচনা না করা ভুল, তবে তারা দরকারী সুবিধা প্রদান করে এমন পরিস্থিতিতে (অন্য উত্তরগুলি দেখুন) খুব কম ব্যবহার করা উচিত (ডিফল্ট হিসাবে নয়)।
এক নম্বর সমস্যা? তারা কেবল খেলনা ডাটাবেসে পরীক্ষা করে। সুতরাং তাদের কোনও ধারণা নেই যে ডেটাবেস বড় হয়ে উঠলে তাদের এসকিউএল ক্রল হবে এবং কাউকে এগিয়ে আসতে হবে এবং পরে এটি ঠিক করতে হবে (যে শব্দটি আপনি শুনতে পাচ্ছেন তা আমার দাঁত পিষে)।
সূচকগুলি ব্যবহার করা হচ্ছে না।
দুর্বল পারফরম্যান্স সহ সম্পর্কযুক্ত সাবকোয়ারিগুলির কারণে
বেশিরভাগ সময় আপনি পরস্পর সম্পর্কিত সাবকোয়ারিগুলি এড়াতে চান। সাবকিউরিটির সাথে, বাইরের কোয়েরি থেকে কোনও কলামের রেফারেন্স পাওয়া গেলে, একটি সাবকোরির সাথে সম্পর্কিত হয়। যখন এটি ঘটে, সাবকিউরিটি প্রতিটি সারিতে ফিরে আসার জন্য কমপক্ষে একবার সম্পাদন করা হয় এবং যদি অন্য শর্তগুলি যদি সম্পর্কযুক্ত সাবকোয়ারি যুক্ত শর্ত প্রয়োগ করার পরে প্রয়োগ করা হয় তবে আরও একবার কার্যকর করা যেতে পারে।
সংক্ষিপ্ত উদাহরণ এবং ওরাকল সিনট্যাক্সটি ক্ষমা করুন, তবে ধরা যাক যে আপনি আপনার কোনও দোকানে ভাড়া নেওয়া সমস্ত কর্মচারী সন্ধান করতে চেয়েছিলেন গতবারের পর থেকে দোকানে একদিনে 10,000 ডলারেরও কম বিক্রয় হয়েছিল।
select e.first_name, e.last_name
from employee e
where e.start_date >
(select max(ds.transaction_date)
from daily_sales ds
where ds.store_id = e.store_id and
ds.total < 10000)
এই উদাহরণের সাবকোয়ারিটি স্টোর_আইডি দ্বারা বাইরের প্রশ্নের সাথে সম্পর্কিত এবং আপনার সিস্টেমে প্রতিটি কর্মচারীর জন্য মৃত্যুদন্ড কার্যকর করা হবে। এই ক্যোয়ারীটি অনুকূল করা যেতে পারে এমন একটি উপায়ে সাবকোরিটিকে একটি ইনলাইন-ভিউতে স্থানান্তর করা।
select e.first_name, e.last_name
from employee e,
(select ds.store_id,
max(s.transaction_date) transaction_date
from daily_sales ds
where ds.total < 10000
group by s.store_id) dsx
where e.store_id = dsx.store_id and
e.start_date > dsx.transaction_date
এই উদাহরণে, ক্লজ থেকে ক্যোয়ারী এখন একটি ইনলাইন ভিউ (আবার কিছু ওরাকল নির্দিষ্ট নির্দিষ্ট বাক্য গঠন) এবং কেবল একবার কার্যকর করা হবে। আপনার ডেটা মডেলের উপর নির্ভর করে এই ক্যোয়ারী সম্ভবত আরও দ্রুত চালিত হবে। কর্মীদের সংখ্যা বাড়ার সাথে সাথে এটি প্রথম প্রশ্নের চেয়ে আরও ভাল পারফর্ম করবে। প্রথম জিজ্ঞাসাটি আসলে আরও ভাল পারফরম্যান্স করতে পারে যদি সেখানে কয়েক জন কর্মী এবং অনেক স্টোর (এবং সম্ভবত অনেকগুলি স্টোরের কোনও কর্মচারী ছিল না) ছিল এবং দৈনিক_সেলার টেবিলটি স্টোর_আইডিতে সূচিযুক্ত করা হয়েছিল। এটি কোনও সম্ভাব্য পরিস্থিতি নয় তবে এটি দেখায় যে কীভাবে একটি সম্পর্কিত সম্পর্কযুক্ত ক্যোয়ারী বিকল্পের চেয়ে আরও ভাল পারফর্ম করতে পারে।
আমি জুনিয়র বিকাশকারীদের বহুবার সাবকিউরিগুলি সংযুক্ত করে দেখেছি এবং এটি সাধারণত পারফরম্যান্সে মারাত্মক প্রভাব ফেলেছিল। তবে, কোনও সম্পর্কযুক্ত সাবকিউয়ারিটি সরিয়ে দেওয়ার পরে আপনি কার্য সম্পাদনকে আরও খারাপ করে দিচ্ছেন না তা নিশ্চিত হয়ে ওঠার আগে এবং পরে ব্যাখ্যা করার পরিকল্পনাটি অবশ্যই লক্ষ্য করুন।
"বাস্তব" ডাটাবেসের পরিবর্তে অ্যাক্সেস ব্যবহার করা। এসকিউএল এক্সপ্রেস , মাইএসকিউএল , এবং এসকিউএলাইটের মতো প্রচুর দুর্দান্ত এবং এমনকি নিখরচায় ডেটাবেস রয়েছে যা আরও ভালভাবে কাজ করবে এবং স্কেল করবে। অ্যাপ্লিকেশনগুলির প্রায়শই অপ্রত্যাশিত উপায়ে স্কেল করা প্রয়োজন।
(বিপুল পরিমাণে) ডেটা সংরক্ষণের জন্য এক্সেল ব্যবহার করা।
আমি সংস্থাগুলি হাজার হাজার সারি ধারণ করে এবং একাধিক ওয়ার্কশিট ব্যবহার করতে দেখেছি (এক্সেলের পূর্ববর্তী সংস্করণে সারি সীমা 65535 এর কারণে)।
এক্সেল রিপোর্ট, ডেটা উপস্থাপনা এবং অন্যান্য কাজের জন্য উপযুক্ত, তবে এটি একটি ডাটাবেস হিসাবে বিবেচনা করা উচিত নয়।
আমি যুক্ত করতে চাই: অত্যন্ত কার্য সম্পাদনকারী কোডের চেয়ে "মার্জিত" কোড পছন্দ করা। ডাটাবেসগুলির বিরুদ্ধে সবচেয়ে ভাল যে কোডটি কাজ করে তা অ্যাপ্লিকেশন বিকাশকারীদের চোখে প্রায়শই কুৎসিত হয়।
অকাল অপটিমাইজেশন সম্পর্কে যে বাজে বিশ্বাস। ডাটাবেসগুলিকে অবশ্যই মূল নকশায় এবং পরবর্তী কোনও বিকাশে কর্মক্ষমতা বিবেচনা করতে হবে। পারফরম্যান্স আমার মতে ডাটাবেস ডিজাইনের 50% (40% ডেটা অখণ্ডতা এবং শেষ 10% সুরক্ষা)। বাস্তব ব্যবহারকারী এবং সত্যিকারের ট্র্যাফিক ডাটাবেসের বিপরীতে স্থাপন করা হলে ডেটাবেসগুলি যা নীচ থেকে উপরে তৈরি করা হয় না তা খারাপভাবে সম্পাদন করে। অকাল অপটিমাইজেশন মানে কোনও অপ্টিমাইজেশন নেই! এর অর্থ এই নয় যে আপনার কোডটি লিখতে হবে যা প্রায়শই খারাপভাবে সঞ্চালিত হবে কারণ আপনি এটি সহজ খুঁজে পেয়েছেন (উদাহরণস্বরূপ কার্সারগুলি যা অন্য কোনও ব্যর্থ না হওয়া পর্যন্ত প্রোডাকশন ডেটাবেজে কখনও অনুমতি দেওয়া উচিত নয়)। এর অর্থ হল যে আপনার প্রয়োজন না হওয়া পর্যন্ত আপনাকে শেষের সামান্য অভিনয় দেখানোর দরকার নেই s ডেটাবেসগুলিতে আরও ভাল কী সম্পাদন করবে সে সম্পর্কে অনেক কিছু জানা যায়,
প্যারামিটারাইজড কোয়েরি ব্যবহার করছেন না। তারা বাঁধন সুন্দর কুশলী করছি এসকিউএল ইনজেকশন ।
এটি অন্য উত্তরে উল্লিখিত ইনপুট ডেটা স্যানিটাইজ না করার একটি নির্দিষ্ট উদাহরণ।
আমি এটি ঘৃণা করি যখন বিকাশকারীরা নেস্টেড নির্বাচিত বিবৃতিগুলি ব্যবহার করে বা এমনকি কোনও প্রশ্নের "নির্বাচন" অংশের মধ্যে একটি নির্বাচিত বিবৃতিটির ফলাফলের কার্য সম্পাদন করে functions
আমি সত্যিই অবাক হয়েছি আমি এখানে অন্য কোথাও দেখতে পাচ্ছি না, সম্ভবত আমি এটিকে উপেক্ষা করেছি, যদিও @ অ্যাডামের সাথে একই রকম ইঙ্গিত পাওয়া গেছে।
উদাহরণ:
SELECT
(SELECT TOP 1 SomeValue FROM SomeTable WHERE SomeDate = c.Date ORDER BY SomeValue desc) As FirstVal
,(SELECT OtherValue FROM SomeOtherTable WHERE SomeOtherCriteria = c.Criteria) As SecondVal
FROM
MyTable c
এই দৃশ্যে, যদি MyTable 10000 সারি প্রদান করে তবে ফলাফলটি এমনভাবে দেখাবে যে কোয়েরিটি সবেমাত্র 20001 কোয়েরিতে চলেছে, কারণ ফলাফলের প্রতিটি লাইনের জন্য একবারে প্রাথমিক কোয়েরি প্লাস করে অন্য টেবিলগুলির জন্য একবার কোয়েরি চালাতে হয়েছিল।
বিকাশকারীরা একটি বিকাশের পরিবেশে এই কাজ করে পালিয়ে যেতে পারেন যেখানে তারা কেবল কয়েকটি সারি ডেটা ফিরিয়ে দিচ্ছেন এবং সাব টেবিলগুলিতে সাধারণত কেবলমাত্র একটি সামান্য পরিমাণের ডেটা থাকে তবে উত্পাদন পরিবেশে, এই ধরণের জিজ্ঞাসা আরও তাত্পর্যপূর্ণ ব্যয়বহুল হয়ে উঠতে পারে টেবিলগুলিতে ডেটা যুক্ত করা হয়।
এর চেয়ে ভাল (প্রয়োজনীয় নিখুঁত নয়) উদাহরণটি হ'ল:
SELECT
s.SomeValue As FirstVal
,o.OtherValue As SecondVal
FROM
MyTable c
LEFT JOIN (
SELECT SomeDate, MAX(SomeValue) as SomeValue
FROM SomeTable
GROUP BY SomeDate
) s ON c.Date = s.SomeDate
LEFT JOIN SomeOtherTable o ON c.Criteria = o.SomeOtherCriteria
এটি প্রধান টেবিলের প্রতিটি রেকর্ডে প্রয়োজনীয় তথ্যের চেয়ে ডাটাবেস অপ্টিমাইজারগুলিকে একসাথে ডেটা বদল করতে দেয় এবং আমি যখন এই সমস্যাটি তৈরি করা হয়েছে তখন আমাকে ঠিক করতে হবে তখন আমি প্রায়শই অনুসন্ধানের গতি 100% বা বৃদ্ধি করে শেষ করি একইসাথে সিপিইউ এবং মেমরির ব্যবহার হ্রাস করার সময় আরও বেশি।
এসকিউএল-ভিত্তিক ডাটাবেসের জন্য:
প্রোডাকশন ডাটাবেসের অভ্যন্তরে কিছু সমস্যা ঠিক করার আগে ব্যাকআপ নেওয়া হচ্ছে না।
সঞ্চিত পদ্ধতিতে সঞ্চিত অবজেক্টগুলিতে (টেবিল, মতামত) ডিডিএল কমান্ড ব্যবহার করা।
সঞ্চিত প্রকট ব্যবহারের ভয় বা ওআরএম কোয়েরিগুলি ব্যবহার করার ভয় যেখানেই কোনও ব্যবহারের পক্ষে দক্ষ / উপযুক্ত।
একটি ডাটাবেস প্রোফাইলার ব্যবহার উপেক্ষা করা, যা আপনাকে বলতে পারে যে আপনার ওআরএম ক্যোয়ারীটি শেষ অবধি রূপান্তরিত হচ্ছে এবং তাই যুক্তিটি যাচাই বা এমনকি ডিআরগিংয়ের জন্য ওআরএম ব্যবহার না করে যাচাই করতে পারে।
স্বাভাবিককরণের সঠিক স্তরটি করছেন না । আপনি নিশ্চিত করতে চান যে ডেটাটি সদৃশ নয়, এবং আপনি প্রয়োজন হিসাবে ডেটা আলাদা করে দিচ্ছেন। আপনাকে এটিও নিশ্চিত করতে হবে যে আপনি খুব বেশি স্বাভাবিকীকরণ অনুসরণ করছেন না এটির ফলে পারফরম্যান্সের ক্ষতি হবে।
ডাটাবেসটিকে কেবল স্টোরেজ মেকানিজম হিসাবে চিকিত্সা করা (যেমন মহিমান্বিত সংগ্রহ গ্রন্থাগার) এবং সুতরাং তাদের প্রয়োগের অধীনস্থ (অন্যান্য অ্যাপ্লিকেশনগুলি যা ডেটা ভাগ করে নেবে)
1 - অযৌক্তিকভাবে এমন কোনও মানতে কোনও ফাংশন ব্যবহার করা হচ্ছে যেখানে সেই সূচকের ফলাফল সহ ধারাটি ব্যবহার করা হচ্ছে না।
উদাহরণ:
where to_char(someDate,'YYYYMMDD') between :fromDate and :toDate
পরিবর্তে
where someDate >= to_date(:fromDate,'YYYYMMDD') and someDate < to_date(:toDate,'YYYYMMDD')+1
এবং কিছুটা হলেও: যে মানগুলির প্রয়োজন তাদের ফাংশনাল ইনডেক্স যুক্ত করা হচ্ছে না ...
2 - তথ্যের বৈধতা নিশ্চিত করতে চেক সীমাবদ্ধতাগুলি যুক্ত করা হচ্ছে না। সীমাবদ্ধতাগুলি ক্যোয়ারী অপ্টিমাইজার দ্বারা ব্যবহার করা যেতে পারে এবং আপনি আপনার আক্রমণকারীদের বিশ্বাস করতে পারেন তা নিশ্চিত করতে তারা অবশ্যই সহায়তা করে। এগুলি ব্যবহার না করার ঠিক কোনও কারণ নেই।
3 - খাঁটি অলসতা বা সময়ের চাপের বাইরে টেবিলগুলিতে অস্বাভাবিক কলাম যুক্ত করা। জিনিসগুলি সাধারণত এইভাবে ডিজাইন করা হয় না, তবে এটির মধ্যে বিকশিত হয়। ভবিষ্যতের বিবর্তনগুলিতে যখন আপনি হারিয়ে যাওয়া ডেটা অখণ্ডতার দ্বারা দংশিত হন তখন শেষ ফলটি, ব্যর্থ না হয়ে, গণ্ডগোল পরিষ্কার করার চেষ্টা করা এক টন কাজ।
এটি ভাবুন, ডেটাবিহীন একটি টেবিলটি নতুন ডিজাইনের জন্য খুব সস্তা। কয়েক মিলিয়ন রেকর্ডের সাথে একটি সারণী যার অখণ্ডতা নেই ... পুনরায় ডিজাইনের জন্য এত সস্তা নয়। সুতরাং, কলাম বা টেবিল তৈরি করার সময় সঠিক নকশাটি করা কোদালগুলিতে এমরোটাইজড।
4 - প্রতি সে ডাটাবেস সম্পর্কে এত বেশি নয় তবে সত্যই বিরক্তিকর। এসকিউএল এর কোড মানের সম্পর্কে যত্নশীল নয়। আপনার এসকিউএল পাঠ্যে প্রকাশ করা হয়েছে তা স্ট্রিং ম্যানিপুলেশন অ্যালগরিদমগুলির স্তূপগুলিতে যুক্তিটি আড়াল করা ঠিক করে না। আপনার সহকর্মী প্রোগ্রামার দ্বারা পাঠযোগ্য এমন উপায়ে পাঠ্যতে এসকিউএল লেখা পুরোপুরি সম্ভব।
এটি আগেও বলা হয়েছিল, তবে: সূচি, সূচক, সূচক । আমি এন্টারপ্রাইজ ওয়েব অ্যাপ্লিকেশনগুলিকে খারাপভাবে সম্পাদন করার অনেকগুলি বিষয় দেখেছি যা কেবলমাত্র একটু প্রোফাইলিং করে (কোন টেবিলগুলিতে প্রচুর পরিমাণে আঘাত হচ্ছিল তা দেখতে) এবং তারপরে সেই টেবিলগুলিতে একটি সূচক যুক্ত করে ঠিক করা হয়েছিল। এটি এসকিউএল লেখার জ্ঞানের পথেও খুব বেশি প্রয়োজন হয় না এবং পরিশোধটি বিশাল।
প্লেগের মতো ডেটা ডুপ্লিকেশন এড়িয়ে চলুন। কিছু লোক অ্যাডভোকেট করেন যে সামান্য প্রতিলিপি ক্ষতিগ্রস্থ হবে না, এবং কার্যকারিতা উন্নত করবে। আরে, আমি বলছি না যে আপনি আপনার স্কিমাটিকে তৃতীয় নরমাল ফর্মে নির্যাতন করতে হবে, যতক্ষণ না এটি এত বিমূর্ত যে এমনকি ডিবিএও জানেন না যে কী হচ্ছে। কেবল বুঝতে পারেন যে আপনি যখনই নাম, বা জিপকোড, বা শিপিং কোডগুলির কোনও সদৃশ করেন তখন অনুলিপিগুলি একে অপরের সাথে সিঙ্কের বাইরে চলে যাবে। এটা ঘটবে. এবং তারপরে আপনি সাপ্তাহিক রক্ষণাবেক্ষণ স্ক্রিপ্টটি চালানোর সময় নিজেকে লাথি মারছেন।
এবং সবশেষে: একটি স্পষ্ট, ধারাবাহিক, স্বজ্ঞাত নামকরণ কনভেনশন ব্যবহার করুন। কোডের একটি ভাল লিখিত টুকরোটি একইভাবে পাঠযোগ্য, একটি ভাল এসকিউএল স্কিমা বা ক্যোয়ারী পড়তে হবে এবং ব্যবহারিকভাবে আপনাকে মন্তব্য করেও কী করছে তা বলা উচিত । ছয় মাসের মধ্যে নিজেকে ধন্যবাদ জানাতে হবে, যখন আপনাকে টেবিলে রক্ষণাবেক্ষণ করতে হবে। "SELECT account_number, billing_date FROM national_accounts""নির্বাচন করুন এসিসিটিএনটিএনবিআর, এনটিএনএল্যাক্টস থেকে বিল্ড্যাট" এর সাথে কাজ করা অসীম সহজ।
বিশ বছরে আমি সবচেয়ে সাধারণ ভুলটি দেখেছি: পরিকল্পনা করার আগে নয়। অনেক বিকাশকারী একটি ডেটাবেস এবং টেবিল তৈরি করে এবং তারপরে অ্যাপ্লিকেশনগুলি তৈরি করার সাথে সাথে টেবিলগুলি ক্রমাগত পরিবর্তন এবং প্রসারিত করে। শেষ ফলাফলটি প্রায়শই একটি জগাখিচুড়ি এবং অকার্যকর এবং পরে পরিষ্কার করা বা সরলকরণ করা কঠিন।
ক) হার্ডকডিং ক্যোয়ারী মানগুলিকে স্ট্রিংয়ে
খ) উইন্ডোজ ফর্ম অ্যাপ্লিকেশনটিতে "অনবটটন প্রেস" ক্রিয়ায় ডাটাবেস ক্যোয়ারী কোড স্থাপন করা
আমি দুজনেই দেখেছি।
এই ভেবে যে তারা যখন ডিবিএ এবং ডেটা মডেলার / ডিজাইনার তখন those অঞ্চলগুলিতে কোনও ধরণের কোনও আনুষ্ঠানিক অনুপ্রবেশ নেই।
এই ভেবে যে তাদের প্রকল্পের জন্য কোনও ডিবিএর দরকার নেই কারণ সেই জিনিসগুলি সবই সহজ / তুচ্ছ।
ডাটাবেসে যে কাজ করা উচিত এবং অ্যাপে করা উচিত সেই কাজগুলির মধ্যে সঠিকভাবে চিহ্নিত করতে ব্যর্থ।
ব্যাকআপগুলি বৈধতা দিচ্ছে না, বা ব্যাক আপ নেওয়া হচ্ছে না।
তাদের কোডে কাঁচা এসকিউএল এম্বেড করা।
স্কট ওয়াল্জের ' ক্লাসিক ডেটাবেস ডেভেলপমেন্ট ভুল এবং তাদের থেকে উত্তরণের পাঁচটি উপায় ' নামে পরিচিত ভিডিওটির একটি লিঙ্ক এখানে
ডাটাবেসগুলির সম্মতিযুক্ত মডেল এবং এটি কীভাবে বিকাশকে প্রভাবিত করে তার কোনও বোঝাপড়া নেই। সূচীগুলি যুক্ত করা এবং সত্যের পরে প্রশ্নগুলি টুইঙ্ক করা সহজ। তবে হটস্পটস, রিসোর্স কনটেন্ট এবং সঠিক ক্রিয়াকলাপের জন্য যথাযথ বিবেচনা ছাড়াই ডিজাইন করা অ্যাপ্লিকেশনগুলিতে (আপনি সবে যা পড়েছেন তা এখনও বৈধ! ধরে নিই) পরবর্তী সময়ে সংশোধন করার জন্য ডাটাবেস এবং অ্যাপ্লিকেশন স্তরের মধ্যে উল্লেখযোগ্য পরিবর্তন প্রয়োজন হতে পারে।
কোনও ডিবিএমএস হুডের নীচে কীভাবে কাজ করে তা বোঝা যাচ্ছে না।
ক্লাচ কীভাবে কাজ করে তা না বুঝে আপনি সঠিকভাবে লাঠি চালনা করতে পারবেন না। এবং আপনি কীভাবে আপনার হার্ডডিস্কের কোনও ফাইলকে সত্যই লিখছেন তা বুঝতে না পেরে আপনি কীভাবে একটি ডাটাবেস ব্যবহার করবেন তা বুঝতে পারবেন না।
বিশেষ করে:
আপনি কি জানেন যে একটি ক্লাস্টার্ড সূচক কী? আপনি যখন আপনার স্কিমা ডিজাইন করেছেন তখন আপনি কি এটি সম্পর্কে চিন্তাভাবনা করেছেন?
আপনি কীভাবে সূচকগুলি সঠিকভাবে ব্যবহার করতে জানেন? কিভাবে একটি সূচক পুনরায় ব্যবহার করবেন? আপনি কি জানেন যে একটি প্রচ্ছদ সূচক কী?
এত দুর্দান্ত, আপনার সূচক আছে। আপনার সূচকে 1 সারি কত বড়? আপনার প্রচুর ডেটা থাকলে সূচকটি কত বড় হবে? সহজেই স্মৃতিতে এটি খাপ খায়? যদি এটি সূচক হিসাবে অকেজো হয় না।
আপনি কি কখনও মাইএসকিউএল এ এক্সপ্ল্লেইন ব্যবহার করেছেন? গ্রেট। এখন নিজের সাথে সৎ হোন: আপনি যা দেখেছেন তার অর্ধেকটা কি আপনি বুঝতে পেরেছেন? না, আপনি সম্ভবত না। ঠিক কর
আপনি ক্যোয়ারী ক্যাশে বুঝতে পারছেন? আপনি কি জানেন যে কোন ক্যোয়ারীটি আন-ক্যাশেবল করে তোলে?
আপনি মাইআইএসএএম ব্যবহার করছেন? আপনি যদি পুরো পাঠ্যের সন্ধানের প্রয়োজন হয় তবে মাইআইএসএএম এর যেভাবেই হোক না কেন। স্পিংক্স ব্যবহার করুন। তারপরে ইনোতে স্যুইচ করুন।