শারীরিক বনাম লজিক্যাল / সফ্টওয়্যার ডাটাবেস রেকর্ড মুছে ফেলুন?

116

কোন রেকর্ডকে লজিক্যাল / সফট ডিলিট করার (যেমন একটি পতাকা নির্ধারণ করে যে রেকর্ডটি মুছে ফেলা হয়েছে) কী করার সুবিধা আসলে বা শারীরিকভাবে রেকর্ডটি মোছার বিরোধিতা করে?

এটি কি সাধারণ অনুশীলন?

এটি কি নিরাপদ?

sql database soft-delete

— user21826
সূত্র

22

ফ্ল্যাগ নয়, মুছে ফেলা টাইমস্ট্যাম্প ব্যবহার করুন।

— ডেভ জার্ভিস

@ ডেভ জারভিস, আপনি কী ব্যাখ্যা করতে পারেন যে টাইমস্ট্যাম্পগুলি ব্যবহার করা পতাকাগুলির আরও ভাল পদ্ধতির?

— সি হেনরি

4

একটি পতাকা সম্পর্কে কোনো তথ্য প্রদান করে না যখন সারি মুছে ফেলা হয়েছে। অস্থায়ী তথ্যের সিস্টেম ডিবাগিং সহ অনেকগুলি ব্যবহার রয়েছে।

— ডেভ জার্ভিস

70

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

যতদূর এটি একটি সাধারণ অনুশীলন - আমি হ্যাঁ বলব, তবে আপনি এটি ব্যবহার করেন কিনা তা আপনার ব্যবসায়ের প্রয়োজনের উপর নির্ভর করে।

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

— ক্রিস শাফার
সূত্র

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

— Coops

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

— ক্রিস শ্যাফার

আহ, আমি সারিটির শর্তে ভাবছিলাম, ব্যবহারকারীর নাম (ব্যবহারকারীর নাম) নয়। আপনি যদি পুরো ইতিহাস বজায় রাখতে চান, সুতরাং যদি কোনও 'অর্ডার' বা সেই ব্যবহারকারীর সাথে লিঙ্কযুক্ত কিছু ছিল, তবে আপনাকে নরম / লজিকাল মোছার জন্য যেতে হবে।

— Coops

11

@ ক্রিসশেফার বিকল্পভাবে, জিইউইডির পরিবর্তে, কেবলমাত্র মুছে ফেলা নয় এমন সারিগুলি সূচী চয়ন করতে পারেন। উদাহরণস্বরূপ: CREATE UNIQUE INDEX ... WHERE DELETED_AT is null(PostgreSQL এ) এবং তারপরে যে কোনও মুছে ফেলার তারিখ সহ সমস্ত সারি সূচিযুক্ত হয় না। (পরিবর্তে এগুলি একটি অনন্য-অনন্য সূচীতে অন্তর্ভুক্ত করা যেতে পারে))

— কাজম্যাগনুস

6

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

— স্টিফান স্টেইগার

27

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

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

ডাউনসাইডগুলির মধ্যে রয়েছে (ইতিমধ্যে উল্লিখিত অন্যদের অন্তর্ভুক্ত নয়):

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

যৌক্তিক, শারীরিক মোছা বা সংরক্ষণাগার ব্যবহার করার সিদ্ধান্ত নেওয়ার সময় আমি নিজেকে এই প্রশ্নগুলি জিজ্ঞাসা করব:

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

— JoshBerke
সূত্র

আপনার ব্যবহারকারীর অ্যাকাউন্টগুলির উদাহরণে, সক্রিয় ও নিষ্ক্রিয় ব্যবহারকারীদের আলাদা আলাদা টেবিলগুলিতে রাখা কি ভাল হবে? যেমন। Activatedটেবিল এবং Deactivatedটেবিল স্কিমা - Id,Name,etc..সারি ইন Activated- 1001,Smith007,etc...যখন সে নিষ্ক্রিয় হয়ে যায়, তখন আমরা স্মিথের জন্য আইডি কলাম বাদে সমস্ত ক্লিয়ার করতে পারি Activatedএবং তাকে যুক্ত করতে পারি Deactivated।

— এরান মোরাড

আপনি যদি আইডি এবং সারিটি ছেড়ে চলে যান তবে সমস্ত ডেটা সরিয়ে নিয়ে কী লাভ? আপনার রেকর্ডটি বিশাল যদি হতে পারে তবে আমি এটিকে একটি মাইক্রো-অপটিমাইজেশন হিসাবে দেখব।

— জোশবার্ক

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

— সিএডি

20

এটি কিছুটা দেরিতে হতে পারে তবে আমি সবাইকে লিনিক্যাল / সফট ডিলিট সম্পর্কে পিনাল ডেভের ব্লগ পোস্টটি পরীক্ষা করার পরামর্শ দিচ্ছি :

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

উপরে বর্ণিত পরিস্থিতিতে ছোট টেবিলের বৃহত্তর টেবিলের সুবিধাগুলি কী কী?

একটি ছোট টেবিল বজায় রাখা সহজ

সূচক পুনর্নির্মাণ অপারেশনগুলি আরও দ্রুত are

সংরক্ষণাগার ডেটা অন্য ফাইলগ্রুপে স্থানান্তরিত করা প্রাথমিক ফাইলগ্রুপের লোড হ্রাস করবে (সমস্ত ফাইলগোষ্ঠী পৃথক সিস্টেমে রয়েছে তা বিবেচনা করে) - এটি ব্যাকআপটিও ত্বরান্বিত করবে।

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

সূচকের আকার আরও কম হবে

একটি ছোট টেবিল আকারের সাথে টেবিলের কার্যকারিতা উন্নত হবে।

— Tohid
সূত্র

16

আপনি কীভাবে এই জাতীয় পদ্ধতি ব্যবহার করে বিদেশী কীগুলির যত্ন নেবেন? 1, 10 বা তার বেশি টেবিল থাকতে পারে যা রেকর্ড মুছে ফেলা হচ্ছে এবং অন্য টেবিলে চলে গেছে!

— sam360

@ sam360 - এটি একটি বড় চ্যালেঞ্জ। সত্যি কথা বলতে, আমি পিকে হ্যান্ডেল করার কারণে এবং টেবিলের মধ্যে সম্পর্কের কারণে আমি ব্যক্তিগতভাবে আমার প্রকল্পগুলিতে উপরের সুপারিশটি প্রয়োগ করতে ব্যর্থ হয়েছি। দুর্ভাগ্যক্রমে এই নিবন্ধে সত্যিকারের বিশ্বের উদাহরণ ছিল না। আমি আমার প্রকল্পের একটিতে একটি সমাধান নিয়ে কাজ করছি, যদি এটি কার্যকর বাস্তবায়িত হয়, আমি আপনার সাথে কোডটি ভাগ করব ...

— তোহিদ

এটাকে কি বলে ? নরম মোছার বদলে?

— ইউজিন

1

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

— তোহিদ

1

আমি বিশ্বাস করি, "আর্কাইভ ডেটা অন্য ফাইলগ্রুপে স্থানান্তরিত করা" ওরাকল-এ পার্টিশন হিসাবে প্রয়োগ করা যেতে পারে, সুতরাং উপরের তালিকাভুক্ত সুবিধা পাওয়া যায় ...

— বেটলিস্টা

14

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

আমি টাইমস্ট্যাম্পগুলি ব্যবহার করে নরম-মুছে ফেলা করেছি, নথির মোছার তারিখটি নিবন্ধন করে:

IsDeleted = 20150310  //yyyyMMdd

প্রতি রবিবার, একটি প্রক্রিয়া ডাটাবেসের উপর দিয়ে যায় এবং IsDeletedক্ষেত্রটি পরীক্ষা করে । যদি বর্তমান তারিখ এবং টাইমস্ট্যাম্পের মধ্যে পার্থক্য N দিনের চেয়ে বেশি হয়, তবে দস্তাবেজটি হার্ড মুছে ফেলা হয়েছিল। দস্তাবেজটি এখনও কিছু ব্যাকআপে উপলব্ধ রয়েছে তা বিবেচনা করে এটি করা নিরাপদ ছিল।

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

TL; DR আমার ব্যবহারের ক্ষেত্রে বড় ডেটা ছিল না। সেক্ষেত্রে আপনার আলাদা পদ্ধতির প্রয়োজন হবে।

— মারিও এস
সূত্র

9

আমি যে প্যাটার্নটি ব্যবহার করেছি তা হ'ল আয়না টেবিল তৈরি করা এবং প্রাথমিক টেবিলটিতে একটি ট্রিগার সংযুক্ত করা, সুতরাং সমস্ত মুছে ফেলা (এবং পছন্দসই আপডেট হলে) আয়না টেবিলে রেকর্ড করা হয়।

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

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

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

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

ব্যতিক্রম:
- গাইড হিসাবে, ব্যবহারকারী, বিভাগ ইত্যাদি সম্পর্কিত "রেফারেন্স" ডেটার জন্য নরম মোছা এবং "ফ্যাক্ট" টাইপ ডেটা, অর্থাৎ লেনদেনের ইতিহাসের জন্য আয়না টেবিলে হার্ড মুছে ফেলা ব্যবহার করুন।

— কোড ওয়ারিয়র
সূত্র

5

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

এটি ভালভাবে কাজ করে কারণ আপনার যদি এখনও অডিট হয় তবে আপনার কাছে ডেটা থাকে। আপনি যদি এটি শারীরিকভাবে মুছে ফেলেন তবে তা চলে গেছে !

— Galwegian
সূত্র

5

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

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

আমি সাধারণত ব্যবহারকারীদের অনির্দিষ্টকালের জন্য "স্থগিত" হিসাবে মুছে ফেলার কথা ভাবি। আপনি কখনই জানতে পারবেন না যে তাদের বৈধভাবে কখন ফিরে আসবে know

— জন ডিউইস
সূত্র

আমাদের এখানে লজিকাল মুছার পরিবর্তে অ্যাকাউন্ট অ্যাক্টিভেশন / নিষ্ক্রিয়করণের মতো কিছু ব্যবহার করা উচিত নয়? @ জন-দেউয়েস

— agগল_ইয়ে

4

আমি প্রায় সবসময় নরম মোছা করি এবং এর কারণ এখানে:

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

— জিয়ানলুকা ঘেটিনি
সূত্র

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

— জিয়ানলুকা ঘেটিনি

3

উত্তর: "এটি কি নিরাপদ?" - এটি আপনার অর্থের উপর নির্ভর করে।

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

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

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

— আয়ান ভারলে
সূত্র

3

যৌক্তিক মোছার সাথে আমি দৃ strongly়ভাবে একমত নই কারণ আপনি অনেকগুলি ত্রুটির মুখোমুখি হয়ে গেছেন।

সমস্ত প্রশ্নের প্রথমত, প্রতিটি ক্যোয়ারী অবশ্যই ইসডিলেটেড ক্ষেত্রের যত্ন নিতে হবে এবং জটিল প্রশ্নের সাথে ত্রুটির সম্ভাবনা বেশি হয়ে যায়।

দ্বিতীয় পারফরম্যান্স: 100000 recs সহ একটি টেবিলের কল্পনা করুন কেবল 3 টি সক্রিয় সাথে, এখন আপনার ডাটাবেসের টেবিলগুলির জন্য এই সংখ্যাটি গুণ করুন; পুরানো (মুছে ফেলা রেকর্ডস) সহ নতুন রেকর্ডগুলির সাথে আরেকটি পারফরম্যান্স সমস্যা হ'ল সম্ভাব্য দ্বন্দ্ব।

আমি দেখতে পাচ্ছি একমাত্র সুবিধা হ'ল রেকর্ডগুলির ইতিহাস, তবে এই ফলাফলটি অর্জনের জন্য অন্যান্য পদ্ধতি রয়েছে, উদাহরণস্বরূপ আপনি লগিং টেবিল তৈরি করতে পারেন যেখানে আপনি তথ্য সংরক্ষণ করতে পারেন: TableName,OldValues,NewValues,Date,User,[..]কোথায় *Valuesথাকতে পারেন varcharএবং এই ফর্মটিতে বিশদটি লিখতে পারেন fieldname : value; [..] বা হিসাবে তথ্য সংরক্ষণ করুন xml।

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

— ম্যাক্স
সূত্র

3

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

আমি যে জিনিসগুলি প্রয়োগ করেছি সেগুলি নীচে নিম্নে দেওয়া হল, আমি আর নরম-মোছার সিদ্ধান্ত নেওয়ার আগে:

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

শুধু আমার দুই সেন্ট মতামত।

— ডেভিড
সূত্র

2

রেফারেন্সিয়াল অখণ্ডতার উপর কঠোর হলে লজিকাল মুছে ফেলা।

টেবিলের ডেটাগুলির অস্থায়ী দিক থাকলে (FROM_DATE - TO_DATE অবধি বৈধ) থাকাকালীন সঠিক চিন্তাভাবনা করা উচিত।

অন্যথায় ডেটাটি অডিটিং টেবিলের দিকে সরান এবং রেকর্ডটি মুছুন।

প্লাস পাশ দিয়ে:

এটি রোলব্যাক করার সহজ উপায় (যদি সম্ভব হয় তবে)।

এটি নির্দিষ্ট সময়ে একটি নির্দিষ্ট সময়ে রাষ্ট্রটি কী ছিল তা সহজেই দেখা যায়।

— pkario
সূত্র

2

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

আপনি যদি আপনার প্রশ্নগুলি অগোছালো হয়ে উঠছেন এবং মুছে ফেলা রেকর্ডগুলি ফিল্টার করার যৌক্তিকতা সম্পর্কে উদ্বিগ্ন হন তবে আপনি কেবল এমন দৃশ্য তৈরি করতে পারেন যা আপনার জন্য ফিল্টারিং করে এবং তার বিরুদ্ধে অনুসন্ধানগুলি ব্যবহার করে। এটি রিপোর্টিং সমাধান এবং এই জাতীয় রেকর্ডগুলির ফাঁস রোধ করবে'll

— বি কিউ।
সূত্র

2

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

অন্যদিকে, প্রয়োজনীয়তাটি হ'ল একবার রেকর্ডটি 'মোছা' হয়ে গেলে, এটি সত্যই এবং অকাট্যভাবে মুছে ফেলা হয়। সিদ্ধান্ত নেওয়ার আগে আপনার স্টেকহোল্ডারদের সাথে কথা বলুন।

— ডেভ
সূত্র

2

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

— axd
সূত্র

1

ক্যাসকেড কার্যকারিতা যেমন অকেজো হিসাবে রেন্ডারিং করা উচিত তেমনি ডাটাবেসটিকে এটি সম্পাদন করতে দেয় না।

সন্নিবেশ হিসাবে সাধারণ জিনিসগুলির জন্য, পুনরায় সন্নিবেশ করার ক্ষেত্রে, তার পিছনের কোডটি দ্বিগুণ হয়।

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

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

আমি যৌক্তিক মোছার বড় ভক্ত নই।

— Taqveem
সূত্র

1

তোহিদের মন্তব্যের জবাব দিতে, আমরা একই সমস্যার মুখোমুখি হয়েছি যেখানে আমরা রেকর্ডের ইতিহাস বজায় রাখতে চেয়েছিলাম এবং আমরা is_deletedকলাম চাই কি না তাও নিশ্চিত নই।

আমি আমাদের অজগর বাস্তবায়ন এবং আমরা আঘাতের অনুরূপ ব্যবহারের ক্ষেত্রে বলছি।

আমরা https://github.com/kvesteri/sqlalchemy-continuum এর মুখোমুখি হয়েছি যা আপনার সম্পর্কিত টেবিলের জন্য সংস্করণ টেবিল পাওয়ার সহজ উপায়। কোডের ন্যূনতম লাইনগুলি যুক্ত করতে, মুছতে এবং আপডেট করার জন্য ইতিহাস ক্যাপচার করে।

এটি কেবল is_deletedকলামের চেয়েও বেশি কাজ করে । এই প্রবেশের ফলে কী ঘটেছে তা যাচাই করতে আপনি সর্বদা সংস্করণ টেবিলটিকে ব্যাক করতে পারেন। এন্ট্রি মুছে ফেলা হয়েছে, আপডেট হয়েছে বা যুক্ত হয়েছে।

এইভাবে is_deletedআমাদের মোটামুটি কলাম থাকা দরকার ছিল না এবং আমাদের মোছার কাজটি বেশ তুচ্ছ ছিল। এইভাবে is_deleted=Falseআমাদের আমাদের কোনও এপিআই চিহ্নিত করার দরকার নেই ।

— ললিত
সূত্র

0

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

EF 6.x বা EF 7 এ সফটওয়্যারলেট বৈশিষ্ট্য হিসাবে যুক্ত করা হয়েছে তবে আপাতত আমাদের একটি কাস্টম বৈশিষ্ট্য তৈরি করতে হবে।

আমি দৃ strongly়ভাবে একটি ডাটাবেস ডিজাইনে সফ্টডিলিটের পরামর্শ দিচ্ছি এবং এটি প্রোগ্রামিং অনুশীলনের জন্য একটি ভাল কনভেনশন।

— সানু অ্যান্টনি
সূত্র

0

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

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

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

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

আপনার প্রয়োজনীয়তা জানতে আপনার উপর নির্ভর করে।

— মার্কো গিগনার্ড
সূত্র

0

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

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

সুতরাং আমরা রাতারাতি একটি স্ক্রিপ্ট চালাই যা এই পরামিতিগুলি অনুসারে লজিকালি মুছে ফেলা চিহ্নিত করে এবং তারপরে দুই / ছয় মাস পরে আজকে যৌক্তিকভাবে মোছা হিসাবে চিহ্নিত যে কোনও কিছুই হার্ড মুছে ফেলা হবে।

স্মার্টফোনের মতো সীমিত মেমরির সাথে ক্লায়েন্ট ডিভাইসে প্রচুর ডাটাবেস থাকার চেয়ে আমরা ডেটা সুরক্ষা সম্পর্কে কম about যে ক্লায়েন্ট সপ্তাহে দু'বার পণ্য চার বছরের জন্য অর্ডার করেন তার ইতিহাসের ৮১,০০০ লাইনের বেশি থাকবে, যার মধ্যে %৫% ক্লায়েন্ট যদি দেখেন তবে সে যত্ন করে না।

— TychaBrahe
সূত্র

0

এটি সমস্ত সিস্টেমের ব্যবহারের ক্ষেত্রে এবং এর ডেটা নির্ভর করে।

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

তবে, সম্ভবত আপনার সিস্টেম এবং এর ডেটা ব্যবহারের ক্ষেত্রে যেমন "উত্তর মেরুতে আবহাওয়া ট্র্যাকিং" রয়েছে। হতে পারে আপনি প্রতি ঘন্টায় একবার তাপমাত্রার পাঠ গ্রহণ করেন এবং দিন শেষে প্রতিদিনের গড় সংগ্রহ করে। সংঘবদ্ধ হওয়ার পরে প্রতি ঘণ্টার ডেটা আর ব্যবহার করা হবে না এবং আপনি সমষ্টি তৈরির পরে ঘন্টার প্রতি ঘন্টা পড়া মুছে ফেলবেন। (এটি একটি তৈরি, তুচ্ছ উদাহরণ।)

মুল বক্তব্যটি হ'ল এগুলি সমস্ত সিস্টেমের ব্যবহারের ক্ষেত্রে এবং এর ডেটাগুলির উপর নির্ভর করে এবং কোনও প্রযুক্তিগত দিক থেকে নিখুঁতভাবে সিদ্ধান্ত নেওয়ার সিদ্ধান্ত নয়।

— হার্ডকোড
সূত্র

0

আমরা হব! সবাই যেমন বলেছিল, এটি পরিস্থিতির উপর নির্ভর করে।

ইউজারনাম বা ইমেইলআইডি এর মতো কলামে আপনার যদি একটি সূচক থাকে - এবং আপনি কখনও একই ব্যবহারকারীর নাম বা ইমেলআইডি আবার ব্যবহার করার প্রত্যাশা করেন না; আপনি একটি নরম মোছা সঙ্গে যেতে পারেন।

এটি বলেছিল, আপনার নির্বাচন অপারেশনটি প্রাথমিক কীটি ব্যবহার করে কিনা তা সর্বদা পরীক্ষা করে দেখুন। যদি আপনার নির্বাচিত বিবৃতিটি একটি প্রাথমিক কী ব্যবহার করে তবে WHERE ধারাটির সাথে একটি পতাকা যুক্ত করা খুব বেশি পার্থক্য করবে না। আসুন একটি উদাহরণ গ্রহণ করুন (সিউডো):

সারণী ব্যবহারকারীগণ (ব্যবহারকারী আইডি [প্রাথমিক কী], ইমেলআইডি, ইস মুছে ফেলা)

SELECT * FROM Users where UserID = 123456 and IsDeleted = 0

ইউজারআইডি কলামে একটি প্রাথমিক কী থাকায় এই কোয়েরিটি পারফরম্যান্সের ক্ষেত্রে কোনও পার্থক্য করবে না। প্রাথমিকভাবে, এটি পিকে ভিত্তিক টেবিলটি স্ক্যান করবে এবং তারপরে পরবর্তী শর্তটি কার্যকর করবে।

যেসব ক্ষেত্রে নরম মোছার কাজগুলি মোটেই কাজ করতে পারে না:

সাইন ইন মূলত সমস্ত ওয়েবসাইট ইমেলআইডিটিকে আপনার অনন্য পরিচয় হিসাবে গ্রহণ করে। আমরা খুব ভাল করেই জানি, একবার ফেসবুক, জি + এর মতো কোনও ওয়েবসাইটে কোনও ইমেলআইডি ব্যবহার করা হয়, এটি অন্য কেউ ব্যবহার করতে পারে না।

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

হ্যাঁ, আমাদের কাছে প্রচুর বিদেশী টেবিল রয়েছে এমন পরিস্থিতিতে পরিচালনা করা বেশ জটিল c

এও মনে রাখবেন যে নরম / লজিকাল ডিলিটগুলি আপনার টেবিলের আকার বাড়িয়ে তুলবে, তাই সূচকের আকার।

— জিতেন
সূত্র

0

আমি ইতিমধ্যে অন্য পোস্টে উত্তর দিয়েছি । তবে আমি মনে করি আমার উত্তরটি এখানে প্রশ্নের সাথে আরও উপযুক্ত।

নরম-Delete জন্য আমার বাস্তবসম্মত সমাধান নিম্নলিখিত কলাম সহ একটি নতুন টেবিল তৈরি করে সংরক্ষণ করা হয়: original_id, table_name, payload, (এবং একটি ঐচ্ছিক প্রাথমিক কী `ID)।

original_idমোছা রেকর্ডের আসল আইডিটি কোথায় , মুছে ফেলা রেকর্ডের table_name টেবিলের নাম ( "user"আপনার ক্ষেত্রে), payloadমোছা রেকর্ডের সমস্ত কলাম থেকে জেএসএন-স্ট্রিংযুক্ত স্ট্রিং।

আমি original_idপরবর্তী তথ্য পুনরুদ্ধারের জন্য কলামে একটি সূচক তৈরি করার পরামর্শ দিই ।

তথ্য সংরক্ষণাগারটি এই উপায় দ্বারা। আপনার এই সুবিধাগুলি থাকবে

ইতিহাসে সমস্ত ডেটা রাখুন

মোছা রেকর্ডের টেবিল কাঠামো নির্বিশেষে যে কোনও টেবিল থেকে রেকর্ড সংরক্ষণাগার করার জন্য কেবলমাত্র এক জায়গা রয়েছে

মূল সারণীতে অনন্য সূচির কোনও উদ্বেগ নেই

মূল সারণীতে বিদেশী সূচকটি পরীক্ষা করার কোনও উদ্বেগ নেই

WHEREমুছে ফেলার জন্য চেক করার জন্য প্রতিটি ক্যোয়ারিতে আর কোনও ধারা নেই

ইতিমধ্যে এখানে আলোচনা করা হয়েছে যে সফট-মোছা বাস্তবে কোনও ভাল ধারণা নয়। সফট-ডিলিট ভবিষ্যতে কিছু সম্ভাব্য ঝামেলা যেমন রেকর্ড গণনা, ...

— transang
সূত্র

আমি ডেটা মুছে ফেলার সমস্ত উপায়ে একটি ব্লগ পোস্ট লিখেছি transang.me/datedia-design-p

— ੈਕਟ-

0

অ্যাডভেঞ্জেটস হ'ল ডেটা সংরক্ষণ / চিরস্থায়ী। স্নিগ্ধ মোছার লক্ষণীয় পরিমাণ সহ টেবিলগুলি থেকে ডেটা জিজ্ঞাসা করা বা পুনরুদ্ধার করার সময় একটি বিবর্তন কর্মক্ষমতা হ্রাস হতে পারে। অন্যদের পূর্ববর্তী উত্তর উল্লেখ করেছি, আমরা: আমাদের ক্ষেত্রে আমরা উভয় সংমিশ্রণ ব্যবহার soft-delete users/clients/customersউদাহরণস্বরূপ, hard-deleteউপর items/products/merchandiseটেবিল যেখানে সদৃশ রেকর্ডগুলি মৌমাছি keept প্রয়োজন হবে না আছে।

— সান্টিয়াগো এসও ছাড়েন
সূত্র

0

এটি মামলার উপর নির্ভর করে, নীচে বিবেচনা করুন:

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

তবুও, আপনি ডেটা গুদামের মডেলটিতে "সফট-মুছুন" বিবেচনা করতে পারেন। উদাহরণস্বরূপ আপনি মুছে ফেলা পণ্যটিতে একটি পুরানো রশিদ দেখছেন *

— ক্রিস খাইরাল্লাহ
সূত্র