ডাটাবেস টেবিলে একটি "রেকর্ড স্থিতি" কলাম থাকা কি খারাপ অভ্যাস?


12

আমাকে প্রথমে পরিষ্কার করতে হবে যে স্থিতি কলামটি সারণীতে রেকর্ড (সারি) দ্বারা উপস্থাপিত কোনও বাস্তব-বিশ্বের আইটেমের অবস্থা প্রতিফলিত করার উদ্দেশ্যে নয় । বরং রেকর্ডের স্ট্যাটাসটিই দেখাতে হবে।

এটি সচল / নিষ্ক্রিয় বা জটিল যেমন অনুমোদিত / মুছে ফেলা / তালাবদ্ধ / মুলতুবি / প্রত্যাখ্যান ইত্যাদির মতো জটিল হতে পারে ইত্যাদি অবস্থা true/ / 1অ্যাক্টিভ বা ম্যাপিংয়ের সাথে বুলিয়ান / সংক্ষিপ্ত পূর্ণসংখ্যা কলাম বা একটি একক-অক্ষর কলামে সংরক্ষণ করা যেতে পারে A= অনুমোদিত।

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

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

আমার প্রশ্নগুলো:

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

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


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

উত্তর:


5

আমি এটি "সফট ডিলিট" হিসাবে জানি; সত্যই তা না হলেও সবেমাত্র "মুছে ফেলা" হিসাবে একটি রেকর্ড চিহ্নিত করা।

এটি কি একটি ভাল অনুশীলন, বা একটি খারাপ অভ্যাস?

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

এটি ডেটা স্বাভাবিককরণকে প্রভাবিত করে?

না, তবে এটি আপনার ডেটা সূচকে প্রভাবিত করবে
নিশ্চিত হয়ে নিন যে আপনি আপনার সূচীতে "মুছে ফেলা" কলামটি অন্তর্ভুক্ত করেছেন, যাতে আপনার সন্ধানগুলিতে এই সারিগুলি যত তাড়াতাড়ি সম্ভব বাদ দেওয়া হয়।

সম্ভাব্য সমস্যাগুলি কী কী?

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

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

একই লক্ষ্য অর্জনের কোনও বিকল্প পদ্ধতি আছে কি? (নোট দেখা)

আসলেই না, না।

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

সহজে হয় না। সারণীর মধ্যে সম্পর্ক নির্ধারণ করার জন্য রিপোর্টিং সরঞ্জামগুলির মতো এই নিয়মগুলি গ্রহণ করার মতো বিষয়গুলির জন্য এটি কার্যকর করার সহজতম উপায় হ'ল ঘোষিত রেফারেন্সিয়াল ইন্টিগ্রিটি (বিদেশী কী ধারা) the এই জাতীয় নিয়মগুলি "স্ট্যাটাস" নির্বিশেষে সমস্ত রেকর্ডে প্রযোজ্য (এবং এর আশেপাশের কোনও উপায় নেই)।

বিকল্পটি হ'ল ট্রিজারগুলি, পদ্ধতিগত কোডের স্নিপেটগুলি ব্যবহার করা যা টেবিলগুলির মধ্যে রেফারেন্সিয়াল অখণ্ডতা প্রয়োগ করে এবং আপনার প্রয়োজনীয় সমস্ত চৌকস, শর্তাধীন জিনিসগুলি করে। এটি আপনার বিশেষ ক্ষেত্রে ভাল, তবে ডিক্লারেটিভ আরআইয়ের বেশিরভাগ সুবিধা উইন্ডোটির বাইরে চলে যায় - আপনার টেবিলগুলির মধ্যে [বাহ্যিকভাবে] সনাক্তকরণযোগ্য সম্পর্ক নেই; এটিই ট্রিগারগুলির মধ্যে "লুকানো"।

কেন ডেটাবেসগুলি "রিসাইকেল বিন" -র মতো বৈশিষ্ট্য বা সারণী-ট্র্যাকিং / পুনরুদ্ধার স্থানীয়ভাবে সরবরাহ করে না, তাই আমরা ইন্টারফেসগুলি উদ্বেগ ছাড়াই প্রকৃত রেকর্ডগুলি মুছতে পারি?

তারা কেন করবে ?

এগুলি ডাটাবেস, সর্বোপরি, ফাইল সিস্টেম বা স্প্রেডশিট নয়।

তারা যা করে, তারা খুব, খুব ভালভাবে করতে পারে।

তারা কি করে না, সম্ভবত খুব বেশি চাহিদা ছিল না।


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

9

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

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


ওরাকল ফ্ল্যাশব্যাক হ'ল আমি যা চাই তার আদর্শ সমাধান। খুব খারাপ এটি ওরাকল মালিকানাধীন।
ADTC

4

এমআরপি / ইআরপি সিস্টেমগুলিতে "মুছে ফেলার জন্য পতাকাঙ্কিত" ক্ষেত্রটি ব্যবহার করা খুব সাধারণ বিষয়।

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

পরিবর্তে, মুছে ফেলার জন্য এটি পতাকাঙ্কিত করে, আপনি রেকর্ডটিতে অভিপ্রায়ের একটি পরিষ্কার মার্কার রেখেছেন এবং পরে একটি নির্ধারিত টাস্ক রেকর্ডটিকে মুছতে পারে যদি এটি যাচাই করে যে সমস্ত সম্পর্কিত টেবিলগুলি আর এটি উল্লেখ না করে।

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


3

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

(আমি বিশ্বাস করি না এটি আপনি "ইতিহাসের সারণী" দ্বারা বোঝাতে চেয়েছিলেন, যা আমি মনে করি আপনি পরিবর্তিত বা মুছে ফেলা রেকর্ডগুলি অন্য টেবিলে অনুলিপি করার আগে কেবল অনুলিপি করেছিলেন)


আকর্ষণীয় ধারণা। এটি কীভাবে বাস্তবায়ন করা যায় তা আমি খতিয়ে দেখব।
এডিটিসি

1

আমি এই ব্যবহারগুলি ক্ষেত্রে এই প্যাটার্নটি ঘন ঘন দেখি এবং ব্যবহার করি:

  • মেটাডেটা যেখানে আপনি কেবল আজ কার্যকর হওয়া মানগুলিই প্রদর্শন করতে চান। উদাহরণস্বরূপ, ড্রপ ডাউন তালিকায় গাড়ি প্রস্তুতকারকদের একটি তালিকা বেছে নেওয়া যেখানে আইডি, ভ্যালু, এনএলবিএডের সারণির মানগুলি = 1 সক্ষম করা হয়েছে, 1, 'ফোর্ড', 1 এবং 2, 'এডসেল', 0, 3, 'টয়োটা' রয়েছে , 1 কেবল ফোর্ড এবং টয়োটার পছন্দ দেয়
  • কেস ম্যানেজমেন্ট সিস্টেমের ক্ষেত্রে যেখানে দৃষ্টান্তটি হ'ল কেস কেবল একবারে এক অবস্থায় থাকতে পারে। এই ক্ষেত্রে টগল কলামটিকে চেক সীমাবদ্ধতার দ্বারা প্রয়োগ করা 0 বা 1 এর মান সহ CURRENT বলা হত। কেস এক রাজ্য থেকে অন্য রাজ্যে চলে যাওয়ার সাথে সাথে অ্যাপ্লিকেশনটি পুরানো রাষ্ট্রের বর্তমান পতাকাটিকে 0 এবং নতুনটিতে 1 এ আপডেট করে

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


1

যদি আপনি আপনার ডেটা প্রতিবেদনের জন্য ব্যবহার করার পরিকল্পনা করেন তবে এটি একটি ভাল অনুশীলন (কোনও বৃহত্তর পর্যায়ে অ্যাপ্লিকেশনটির রিপোর্ট থাকা দরকার)।

আপনার অ্যাপ্লিকেশনটির গতি বাড়ানোর জন্য, আপনার প্রতিবেদনের সরঞ্জামগুলি আপনার ডেটাবেজে চালিত হওয়া উচিত নয়। এর মতো আপনাকে অন্য একটি ডাটাবেসে একটি অনুলিপি / সিঙ্ক করতে হবে।

আমি recordStatusকেবল দুটি স্টেট ACTIVEবা টাইমস্ট্যাম্পের CANCELLEDসাথে একত্রে ব্যবহার করি lastUpdatedOn। আমি এর recordStatusপরিবর্তে ব্যবহার করি statusযা সাধারণত একটি ব্যবসায়িক অর্থ হয়।

আমি যখন অ্যাপ্লিকেশনটির সাথে রিপোর্টিং ডাটাবেস সিঙ্ক করছি, আমি lastUpdatedOnরিপোর্টিংয়ের দিক থেকে আমি কোনটি প্রতিস্থাপন করতে যাচ্ছি তা জানতে একটি ফিল্টার করি।

প্রতিবেদনের পক্ষে আমার কাছে ক্ষেত্র recordStatusবা lastUpdatedOnক্ষেত্রগুলি থাকবে না কারণ এটি সাধারণত প্রকাশিত হয় না। যেমন আমি যখন কোনও CANCELLEDস্থিতি দেখি আমি প্রতিবেদনের পাশ থেকে রেকর্ডটি মুছে ফেলব তবে কেবল সক্রিয় রেকর্ড রয়েছে।

এটি অন্যান্য ধরণের স্টোর যেমন আর্কাইভ বা ব্যাকআপগুলিতে প্রসারিত হতে পারে যেখানে প্রায় সম্পূর্ণ সিঙ্ক্রোনাইজেশন প্রয়োজন required তবে রিপোর্ট করা আরও সাধারণ উদ্দেশ্য common

আপনার উদাহরণ লক্ষ করুন Approved, New, Pendingএকটি ভাল ধারণা যে হিসাবে একটি ব্যবসা এটা অর্থ যেখানে এটা জ্ঞান ব্যবসা জ্ঞানী তোলে শুধুমাত্র যেতে হবে রয়েছে একটি সাধারণ ক্ষেত্র হিসেবে করা হয় না।

লক করা হিসাবে, ব্যবহার করুন versionNoযা আপনার রেকর্ডের জন্য একটি আশাবাদী লক সরবরাহ করে।

পরিবর্তে অন্য বিকল্পটি recordStatusহ'ল recordActiveএবং এটি এমন একটি হিসাবে সংরক্ষণ করা হয়েছে booleanযা কম জায়গা এবং কম সূচী গ্রহণ করে তবে আমি ভবিষ্যতের প্রয়োজনগুলি সম্পর্কে উদ্বিগ্ন যা আপনি আশা করতে পারেন না।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.