কীভাবে মুছে ফেলা হবে ডাটাবেসে?


44

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


আমি উল্লেখ করতে ভুলে গেছি যে দ্বিতীয় ক্ষেত্রে পতাকাঙ্কিত রেকর্ডগুলি কিছু যুক্তিসঙ্গত সময় কাটিয়ে যাওয়ার পরে মুছে ফেলা বা সরানো দরকার।
অ্যাবি

আপনি কোন ডাটাবেস ব্যবহার করছেন?
ইভান ক্যারল

টেম্পোরাল টেবিলটি এসকিউএল সার্ভার 2016 এবং তারপরের জন্য সেরা সমাধান।
সমীর

উত্তর:


37

হ্যাঁ, আমি অবশ্যই দ্বিতীয় বিকল্পের জন্য যাব, তবে আমি আরও একটি ক্ষেত্র একটি তারিখের ক্ষেত্র যুক্ত করব।

সুতরাং আপনি যোগ করুন:

delete       boolean
delete_date  timestamp

এটি আপনাকে মুছে ফেলা কর্মের জন্য সময় দিতে দেয়।

সময় যদি এক ঘন্টার কম হয় তবে কেউ মুছে ফেলতে পারে না।

মুছে ফেলা মুছে ফেলা মুছে ফেলার জন্য কেবল একটি সঞ্চিত পদ্ধতি তৈরি করুন যা মুছে ফেলা হবে এমন প্রতিটি প্রবেশকে এক ঘন্টারও বেশি সময় নির্ধারণ করে সেট করে এবং প্রতি 24 ঘন্টা সময় চলমান ক্রোন ট্যাব হিসাবে রাখবে

ঘন্টাটি কেবল একটি উদাহরণ।


বিকল্পভাবে, আপনার অন্য একটি পতাকা থাকতে পারে - cleanedবা কিছু - যা নির্দেশ করে যে এই রেকর্ডের সাথে সম্পর্কিত ডেটা সঠিকভাবে, ব্যাপকভাবে মোছা হয়েছে। cleanedসত্য না হলে রেকর্ডটি মুছে ফেলা যায়, সেক্ষেত্রে এটি অপরিবর্তনযোগ্য।
গৌরব

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

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

দ্রষ্টব্য: মুছুন মাইএসকিউএল-এ সংরক্ষিত শব্দ।
জেসন রিকার্ড

মনে রাখবেন যে deletedআপনি যখন অপসারণবিহীন সারিগুলির জন্য অনুসন্ধান করছেন তখন আপনার ক্ষেত্রের একটি ফিল্টারড সূচক কর্মক্ষমতা বাড়িয়ে তুলতে পারে
রস প্রেসার

21

আমাদের অ্যাপ্লিকেশন আমরা না সত্যিই ডিলিট কিছু সময়ে একটি ব্যবহারকারী যাহাই হউক না কেন অনুরোধ (আমাদের ক্লায়েন্টদের নিয়ন্ত্রিত পরিবেশে যেখানে কিছু মোছার সম্ভাব্য আইনি সমস্যার হতে পারে আছে)।

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

এই পথে:

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

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


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

  • এসকিউএল সার্ভার ২০১ introduced "সিস্টেম সংস্করণযুক্ত টেম্পোরাল টেবিলগুলি" প্রবর্তন করেছিল যা আপনার জন্য এই কাজটি অনেক কিছু করে, এবং আরও কিছু দুর্দান্ত সিনট্যাকটিক চিনি হিসাবে maintainতিহাসিক প্রশ্নগুলি নির্মাণ ও বজায় রাখা সহজতর করার জন্য সরবরাহ করা হয় এবং তারা স্কিমার পরিবর্তনের একটি উপসেট সমন্বয় করে inate বেস এবং ইতিহাস সারণী। তারা তাদের সতর্কতা ছাড়াই নয়, তবে তারা এই ধরণের উদ্দেশ্যে একটি শক্তিশালী হাতিয়ার। অন্যান্য ডিবি সিস্টেমেও অনুরূপ বৈশিষ্ট্য পাওয়া যায়।

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


আপনি কীভাবে কলামগুলি মুছে ফেলার এবং নাম পরিবর্তন করতে ডিল করেন? অযোগ্য সমস্ত সেট?
স্টিজন

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

9

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


7

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

@ স্প্রেডজির মতো আমিও delete_dateএক্স-ঘন্টা / দিন / যে কোনও কিছু পরে পুনরুদ্ধার করা হয়নি এমন প্রোগ্রামগুলিতে রেকর্ডগুলি শুদ্ধ করতে সক্ষম হতে কলাম যুক্ত করার পরামর্শ দিয়েছি ।


4

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


3

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


এটি কেবল দেখার বিষয় নয়। সেটটিতে যে কোনও অপারেশন করা হচ্ছে তার "মুছে ফেলা" রেকর্ডগুলি বাদ দিতে হবে।
অ্যাবি

2

স্প্রেডজি যা বলেছিল তার অনুরূপ, আমরা আমাদের সমস্ত অ্যাপ্লিকেশনগুলিতে মুছে ফেলার জন্য একটি টাইমস্ট্যাম্প ক্ষেত্রটি ব্যবহার করি। বুলিয়ান অত্যধিক অপরিহার্য, কারণ টাইমস্ট্যাম্প সেট হওয়ার ফলে ইঙ্গিত হয় যে রেকর্ডটি মোছা হয়েছে। এইভাবে, আমাদের PDO সর্বদা AND (deleted IS NULL OR deleted = 0)নির্বাচিত বিবৃতিগুলিতে যুক্ত করে, যদি না মডেল স্পষ্টভাবে মুছে ফেলা রেকর্ডগুলি অন্তর্ভুক্ত না করে requests

আমরা বর্তমানে টেবিলগুলি ছাড়া ব্লব বা পাঠ্যগুলিতে কোনও আবর্জনা সংগ্রহ করি না; রেকর্ডগুলি ভালভাবে স্বাভাবিক করা থাকলে স্থানটি তুচ্ছ এবং deletedক্ষেত্রটি সূচীকরণটি নির্বাচনের গতিতে সীমিত প্রভাব ফেলবে।


0

আপনি বিকল্পভাবে ব্যবহারকারীদের (এবং বিকাশকারীদের) উপর নজর রাখতে পারেন এবং 'আপনি কি নিশ্চিত?', 'আপনি কি নিশ্চিত?' এবং 'আপনি কি নিখুঁত, ভাল এবং সত্যই নিশ্চিত?' রেকর্ড মোছার আগে প্রশ্ন। হালকা সামান্য কিন্তু বিবেচ্য মূল্য।


0

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

তদুপরি, লিখিত প্রতিটি প্রশ্নের জন্য সেগুলি বিশেষভাবে বাদ দিতে হবে এবং সূচিগুলিও সেগুলি বিবেচনা করা উচিত।

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

এর পরে, মুছে ফেলা সন্নিবেশ-মুছে ফেলা হয়। মুছে ফেলা সারিটি প্রথমে তার 'মুছে ফেলা' স্কিমা অংশে .োকানো হবে। মূল সারণীতে প্রশ্নে থাকা সারিটি মুছতে পারে। অতিরিক্ত যুক্তি অবশ্য লাইন বরাবর কোথাও যুক্ত করা প্রয়োজন। বিদেশী কী লঙ্ঘন পরিচালনা করা যেতে পারে।

বিদেশী কীগুলি সঠিকভাবে পরিচালনা করতে হবে। যৌক্তিকভাবে একটি সারি সরিয়ে ফেলা খারাপ অভ্যাস তবে এর প্রাথমিক / অনন্যটির অন্যান্য টেবিলগুলিতে কলাম রয়েছে যা এটি উল্লেখ করেছে। এটি কোনওভাবেই হওয়া উচিত নয়। একটি নিয়মিত কাজ বিধবা সারিগুলি সরিয়ে ফেলতে পারে (সারিগুলির প্রাথমিক কীগুলির কোনও বিদেশী কী থাকা সত্ত্বেও অন্য টেবিলগুলিতে কোনও রেফারেন্স নেই This এটি অবশ্য ব্যবসায়ের যুক্তি।

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

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

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

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