পরিচয় কলাম পুনরায় বীজ: কখন প্রয়োজন?

Question

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

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

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

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

আগাম ধন্যবাদ!

Answer 1

এটি হ'ল, যখন সারণি সারিটি মুছে ফেলা হয়, পরবর্তী পোকাগুলি অবশ্যই পুনরায় ব্যবহার করা উচিত।

আপনার প্রভাষকটি কোন মহাবিশ্ব থেকে ??

এটি স্থূলভাবে অদক্ষ। যদি আপনি এটি করার চেষ্টা করেন, আপনি 10 এর গুণক দ্বারা আপনার কর্মক্ষমতা সম্ভাবনাগুলি কেটে ফেলবেন।

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

মাইএসকিউএলে, ইনোডিবি PRIMARY KEYপ্রতিটি টেবিলের জন্য একটি অনন্য অস্তিত্ব প্রয়োজন requires তবে প্রয়োজনের পরিধি এটি। কীটি একটি স্ট্রিংও হতে পারে।

গ্যাপগুলি কোনও অসুবিধা নয় , ব্যবহারকারী এবং ডিবিএর জন্য সুবিধা ।

আমি এমন একটি ক্ষেত্রে ভাবতে পারি যেখানে ফাঁকবিহীন সুবিধাজনক হবে - একসাথে 100 টি সারির গ্রুপে বিভক্ত হওয়া। তবে ব্যবহার করার একটি সহজ উপায় আছে LIMIT 100,1।

পারফরম্যান্সে গ্যাপের শূন্য প্রভাব রয়েছে। এর মধ্যে অ-সংখ্যাসূচক সূচকগুলি অন্তর্ভুক্ত রয়েছে। এবং অ-অনন্য সূচী। এবং যৌগিক সূচকগুলি।

অবশ্যই, আপনি আইডির বাইরে চলে যেতে পারেন। আমি মনে করি মাইএসকিউএল ব্যবহারের প্রায় 2 দশকের মধ্যে এটি দুবার ঘটতে দেখেছি। আমি পাশাপাশি গ্রহাণু দ্বারা আঘাত করা সম্পর্কে উদ্বিগ্ন হতে পারে। এটি আমার জিনিস-যা-আমাকে-জাগ্রত রাখুন-রাতের তালিকায় কম।

ফাঁক (অন্তত) থেকে ঘটতে: INSERT IGNORE, IODKU, REPLACE, DELETE, ROLLBACK(স্পষ্ট, বা কারণে বিপর্যস্ত), মাল্টি মাস্টার (Galera এবং গ্রুপ আত্ম সহ) রেপ্লিকেশন। আপনি কি সত্যিই তাদের জন্য কাজের সাথে আসতে চান ?!

লেকচারার যে সন্দেহজনক তা বলে আমাদের অন্য কোনও কিছু নির্দ্বিধায় নির্দ্বিধায় করুন।

Answer 2

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

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

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

Answer 3

পিকে আইডি মানগুলির পুনঃব্যবহারে সমস্যা রয়েছে এবং সাধারণত এড়ানো উচিত।

প্রথমত, অটো_সংশ্লিষ্ট কলামগুলি প্রয়োগ ফাঁকবিহীন হওয়ার গ্যারান্টি সরবরাহ করে না। প্রকৃতপক্ষে ফাঁকগুলি ঘটবে যদি আপনি একটি স্বয়ংবৃদ্ধি কলামে একটি সন্নিবেশ রোলব্যাক করেন।

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

তৃতীয়ত, bigint unsignedএকটি অত্যন্ত বড় সন্নিবেশ হার দেওয়া হলেও উল্লেখযোগ্য সময়ের জন্য আইডি শেষ হবে না।

ফাঁকাগুলির সাথে সবচেয়ে বড় ব্যথাটি অডিটরদের কাছে চলে আসছে যারা এটির নিরীক্ষণের ত্রুটি জোর দেয়। ডিবিএর জন্য তারা জানে যে ফাঁকগুলি বিদ্যমান এবং কেন।

Answer 4

আমি অন্য সবার মন্তব্যকে প্রতিধ্বনিত করব না যে পিকে পুনরায় ব্যবহার করা একটি খারাপ ধারণা তবে আমি এমন অনেক সময় পেরিয়ে এসেছি যেখানে একটি পরিচয় কলামটি পুনরায় বীজযুক্ত করা দরকার।

পিকে সূচকেই দুর্নীতি।

অনুমোদিত যে এটি বহু বছর আগে এমএস-এসকিউএল এবং অনেকগুলি ব্যবহার করছিল তবে এটি এখনও প্রাসঙ্গিক। বহু বছর আগে আমি যে সংস্থার জন্য কাজ করি তার জন্য কেউ ভেবেছিল যে ক্লায়েন্টরা তাদের ব্যবহারের জন্য খুব বেশি বয়স্ক হয়ে যাওয়ার পরে পিসিগুলি আমাদের 150+ দূরবর্তী অবস্থানগুলিতে সার্ভার হিসাবে পুনরায় ব্যবহার করা ভাল এবং পরে সেগুলি একটি পায়খানাতে আটকে রাখা ভাল idea কোন বায়ুচলাচল ছাড়া যখন না কারণ আমরা সবাই জানি যে একটি ক্ষুদ্র কক্ষের এক জঞ্জাল 10 বছরের পুরানো কম্পিউটারের 120++ চলমান মিশন সমালোচনামূলক ডাটাবেসের টেম্পস সহ কেবল ভাল জিনিসই ফলস্বরূপ হতে পারে। 40% ব্যর্থতার হারের মতো এবং আমি আমার ক্যারিয়ার পছন্দটি নিয়ে পুনর্বিবেচনা করি। আমরা কর্পস সদর দফতরে তথ্যগুলি পুনরায় প্রতিলিপি করব তবে প্রায়শই না করা, এই ব্যর্থতার ফলে ডেটাবেসগুলিতে খারাপ কিছু ঘটতে পারে। এইগুলির মধ্যে একটি হ'ল ডেটাবেসটি হ'ল ডেটাবেসগুলির দুর্গম সূচকগুলি যা ডেটাবেস এবং প্রতিলিপি প্রক্রিয়া দখল করবে। এই দুর্দান্ত পরিবেশে দু'বার প্রতিলিপি তৈরির একমাত্র সমাধান হ'ল সূচিগুলি পুনরায় পরীক্ষা করা এবং তারপরে পুনরায় প্রতিস্থাপন করা। আমরা সার্ভারগুলি পুরোপুরি খননের আগে পরে প্রতিস্থাপন করেছি।