এই প্রশ্নের যথাযথ উত্তর দেওয়ার জন্য আপনাকে প্রথমে সিদ্ধান্ত নিতে হবে: "মুছে ফেলা" এর অর্থ এই সিস্টেম / অ্যাপ্লিকেশনটির প্রসঙ্গে কী?
উত্তর দেওয়ার জন্য যে প্রশ্ন, আপনি এখনও অন্য প্রশ্নের উত্তর করা প্রয়োজন: কেন রেকর্ড মুছে হচ্ছে?
ব্যবহারকারীর ডেটা মুছতে পারে এমন অনেকগুলি ভাল কারণ রয়েছে। সাধারণত আমি দেখতে পাচ্ছি যে ঠিক একটি কারণ (প্রতি টেবিল) কেন মুছে ফেলার প্রয়োজন হতে পারে। কয়েকটি উদাহরণ হ'ল:
- ডিস্ক স্থান পুনরায় দাবি করতে;
- ধারণ / গোপনীয়তা নীতি অনুসারে হার্ড-মুছে ফেলার প্রয়োজন;
- দূষিত / আশাহীনভাবে ভুল ডেটা, মুছে ফেলা সহজ এবং পুনরায় জেনারেট করার চেয়ে মেরামত করা।
- সংখ্যাগরিষ্ঠ সারির মুছে ফেলা হয়, যেমন একটি লগ টেবিল এক্স রেকর্ড সীমাবদ্ধ / দিন।
হার্ড-মুছে ফেলার কয়েকটি খুব দুর্বল কারণও রয়েছে (পরবর্তী কারণগুলির জন্য আরও):
- একটি ছোটখাটো ত্রুটি সংশোধন করতে। এটি সাধারণত বিকাশকারী অলসতা এবং একটি বৈরী UI- কে আন্ডারস্কোর করে।
- কোনও লেনদেন "অকার্যকর" করার জন্য (যেমন চালানটি কখনই বিল করা উচিত হয়নি)।
- কারণ আপনি পারেন ।
কেন, আপনি জিজ্ঞাসা করছেন, এটি সত্যিই এত বড় ব্যাপার? ভাল ওলে কি দোষ DELETE?
- এমনকি কোনও সিস্টেমে এমনকি প্রত্যেকেই অর্থের সাথে জড়িত, হার্ড-মুছে ফেলা সমস্ত ধরণের অ্যাকাউন্টিং প্রত্যাশা লঙ্ঘন করে, এমনকি কোনও সংরক্ষণাগার / সমাধিস্থল সারণিতে সরিয়ে নেওয়া হলেও। এটি পরিচালনা করার সঠিক উপায় হ'ল একটি প্রতারণামূলক ঘটনা ।
- সংরক্ষণাগার টেবিলগুলির লাইভ স্কিমা থেকে আলাদা করার প্রবণতা রয়েছে। যদি আপনি এমনকি একটি নতুন যুক্ত হওয়া কলাম বা ক্যাসকেড সম্পর্কে ভুলে যান তবে আপনি স্থায়ীভাবে সেই ডেটাটি হারিয়ে ফেলেছেন।
- হার্ড মুছে ফেলা খুব ব্যয়বহুল অপারেশন হতে পারে, বিশেষত ক্যাসকেডগুলির সাথে । অনেক লোক বুঝতে পারে না যে একাধিক স্তরের ক্যাসকেডিং (বা কিছু ক্ষেত্রে কোনও ক্ষেত্রে) ক্যাসকেডিং, ডিবিএমএসের উপর নির্ভর করে) এর ফলে সেট অপারেশনগুলির পরিবর্তে রেকর্ড-স্তরীয় ক্রিয়াকলাপ হবে।
- বারবার, ঘন ঘন হার্ড মুছে ফেলা সূচি খণ্ডনের প্রক্রিয়াটিকে গতি দেয়।
সুতরাং, নরম মোছা ভাল, তাই না? না সত্যিই না:
- ক্যাসকেড সেট আপ করা অত্যন্ত কঠিন হয়ে পড়ে। আপনি প্রায় সর্বদা ক্লায়েন্টের কাছে এতিম সারি হিসাবে উপস্থিত থেকে শেষ হয়।
- আপনি কেবল একটি মুছে ফেলার ট্র্যাক পাবেন । সারিটি যদি একাধিকবার মুছে ফেলা এবং মুছে ফেলা হয় তবে কী হবে?
- পঠন কর্মক্ষমতা ক্ষতিগ্রস্থ হয়, যদিও এটি বিভাজন, দর্শন এবং / অথবা ফিল্টার সূচকগুলির সাথে কিছুটা কমিয়ে আনা যায়।
- আগে ইঙ্গিত হিসাবে, এটি কিছু পরিস্থিতিতে / এখতিয়ারে অবৈধ হতে পারে।
সত্যটি এই যে উভয় পদ্ধতিরই ভুল। মুছে ফেলা ভুল। যদি আপনি আসলে এই প্রশ্নটি জিজ্ঞাসা করছেন তবে এর অর্থ আপনি লেনদেনের পরিবর্তে বর্তমান অবস্থার মডেলিং করছেন। এটি ডাটাবেস-জমিতে একটি খারাপ, খারাপ অভ্যাস।
উদি দহন এটি মুছুন না - লিখে ফেলুন - এ সম্পর্কে লিখেছেন । নেই সবসময় কিছু বাছাই কাজটি লেনদেন, কার্যকলাপ , অথবা (আমার পছন্দের শব্দ) ঘটনা যা আসলে "ডিলিট" প্রতিনিধিত্ব করে। যদি আপনি পরবর্তীকালে পারফরম্যান্সের জন্য একটি "বর্তমান অবস্থা" টেবিলের মধ্যে অস্বীকৃতি জানাতে চান তবে এটি ঠিক আছে, তবে আপনি ট্রানজেকশনাল মডেলটিকে পেরেক দেওয়ার পরে করুন , আগে নয়।
এই ক্ষেত্রে আপনার "ব্যবহারকারী" রয়েছে। ব্যবহারকারীরা মূলত গ্রাহক। গ্রাহকদের আপনার সাথে একটি ব্যবসায়িক সম্পর্ক রয়েছে। এই সম্পর্কটি কেবল পাতলা বাতাসে বিলুপ্ত হয় না কারণ তারা তাদের অ্যাকাউন্ট বাতিল করে দেয়। আসলে কী হচ্ছে তা হ'ল:
- গ্রাহক অ্যাকাউন্ট তৈরি করে
- গ্রাহক অ্যাকাউন্ট বাতিল করে
- গ্রাহক অ্যাকাউন্ট পুনর্নবীকরণ করে
- গ্রাহক অ্যাকাউন্ট বাতিল করে
- ...
প্রতিটি ক্ষেত্রে, এটি একই গ্রাহক এবং সম্ভবত একই অ্যাকাউন্ট (যেমন প্রতিটি অ্যাকাউন্ট পুনর্নবীকরণ একটি নতুন পরিষেবার চুক্তি)। তাহলে আপনি সারিগুলি মুছছেন কেন? এটি মডেল করা খুব সহজ:
+-----------+ +-------------+ +-----------------+
| Account | --->* | Agreement | --->* | AgreementStatus |
+-----------+ +-------------+ +----------------+
| Id | | Id | | AgreementId |
| Name | | AccountId | | EffectiveDate |
| Email | | ... | | StatusCode |
+-----------+ +-------------+ +-----------------+
এটাই. এখানেই শেষ এটা পেতে ওখানে যাও. আপনার কখনও কোনও কিছু মুছতে হবে না। উপরেরটি একটি মোটামুটি সাধারণ নকশা যা একটি ভাল ডিগ্রিটি নমনীয়তা সমন্বিত করে তবে আপনি এটিকে কিছুটা সহজ করতে পারেন; আপনি সিদ্ধান্ত নিতে পারেন যে আপনার "চুক্তি" স্তরটির প্রয়োজন নেই এবং কেবল "অ্যাকাউন্ট" একটি "অ্যাকাউন্টস্ট্যাটাস" টেবিলে যেতে হবে।
যদি আপনার আবেদনের ঘন ঘন প্রয়োজন সক্রিয় চুক্তি / অ্যাকাউন্টগুলির একটি তালিকা পেতে হয় তবে এটি একটি (সামান্য) কৌশলযুক্ত ক্যোয়ারী, তবে এর জন্য মতামতগুলি কী:
CREATE VIEW ActiveAgreements AS
SELECT agg.Id, agg.AccountId, acc.Name, acc.Email, s.EffectiveDate, ...
FROM AgreementStatus s
INNER JOIN Agreement agg
ON agg.Id = s.AgreementId
INNER JOIN Account acc
ON acc.Id = agg.AccountId
WHERE s.StatusCode = 'ACTIVE'
AND NOT EXISTS
(
SELECT 1
FROM AgreementStatus so
WHERE so.AgreementId = s.AgreementId
AND so.EffectiveDate > s.EffectiveDate
)
এবং তুমি করে ফেলেছ. এখন আপনার কাছে নরম মোছার সমস্ত সুবিধা সহ কিছু আছে তবে কোনও ত্রুটি নেই:
- এতিম রেকর্ডগুলি একটি ইস্যু নয় কারণ সমস্ত রেকর্ড সর্বদা দৃশ্যমান; যখনই প্রয়োজন হয় আপনি কেবল আলাদা ভিউ থেকে নির্বাচন করুন।
- "মোছা" হ'ল একটি অবিশ্বাস্যভাবে সস্তার অপারেশন - কেবল ইভেন্ট টেবিলের মধ্যে একটি সারি সন্নিবেশ করা।
- কোনও ইতিহাস হারানোর কোনও সম্ভাবনা নেই, কখনই , আপনি যতই খারাপভাবে স্ক্রু করেন তা নয়।
- আপনার যদি প্রয়োজন হয় তবে আপনি হার্ড-ডিলিট করতে পারেন (উদাহরণস্বরূপ গোপনীয়তার কারণে), এবং মুছে ফেলা পরিষ্কার হয়ে যাবে এবং অ্যাপ্লিকেশন / ডাটাবেসের অন্য কোনও অংশে হস্তক্ষেপ করবে না এমন জ্ঞানের সাথে স্বাচ্ছন্দ্য বোধ করতে পারেন।
মোকাবেলা করার একমাত্র ইস্যুটি হল পারফরম্যান্স ইস্যু। বেশিরভাগ ক্ষেত্রেই এটি ক্লাস্টারড ইনডেক্সের কারণেই একটি অ-ইস্যু হিসাবে প্রমাণিত হয়েছে AgreementStatus (AgreementId, EffectiveDate)- সেখানে খুব কম আই / ও রয়েছে seeking তবে এটি যদি কোনও সমস্যা হয় তবে তা সমাধানের উপায় রয়েছে, ট্রিগারগুলি, সূচকযুক্ত / উপাদানযুক্ত দর্শনগুলি, অ্যাপ্লিকেশন-স্তরের ইভেন্টগুলি ইত্যাদি ব্যবহার করে solve
পারফরম্যান্স সম্পর্কে খুব তাড়াতাড়ি চিন্তা করবেন না - যদিও নকশাটি সঠিকভাবে পাওয়া আরও গুরুত্বপূর্ণ, এবং এই ক্ষেত্রে "ডান" মানে ডাটাবেসটিকে যেভাবে একটি ডাটাবেস ব্যবহার করা হয় তা ট্রানজেকশনাল সিস্টেম হিসাবে ব্যবহার করা ।