আইটেমগুলির একটি সারণীতে (সম্ভাব্য) কয়েক মিলিয়ন রেকর্ড থাকবে।
এটি আসলে এতটা নয়, এসকিউএল সার্ভার দক্ষতার সাথে পরিচালনা করতে পারে তা given অবশ্যই, আমি আমার আগের একটি কাজের কথা মনে করি যেখানে সবচেয়ে বড় টেবিলগুলির মধ্যে একটিতে (একটি একক উদাহরণ সিস্টেম) 2 মিলিয়ন সারি ছিল এবং এটি ছিল আমার সাথে সবচেয়ে বেশি মোকাবেলা করা। তারপরে পরবর্তী কাজটিতে কয়েক মিলিয়ন সারি থাকা কয়েকটি টেবিলের সাথে 17 টি প্রোডাকশন উদাহরণ রয়েছে এবং এটি সমস্ত 1 মিলিয়ন সারিগুলির একাধিক ফ্যাক্ট টেবিল সহ ডেটা গুদামে একত্রিত হয়েছিল। আমাকে ভুল করবেন না, আমি কয়েক মিলিয়ন সারিতে ঠাট্টা করছি না, আমি কেবল এটির উপর জোর দিচ্ছি যে একটি ভাল ডেটা মডেল এবং সঠিক সূচক (এবং সূচী রক্ষণাবেক্ষণ) দিয়ে এসকিউএল সার্ভার অনেক কিছু পরিচালনা করতে পারে ।
আইটেমের 50% পর্যন্ত যে কোনও সময় "অনুমোদিত নয়" be
হুম। এটি ঠিক শোনাচ্ছে না। "অনুমোদিত" প্রবেশের হার নতুন এন্ট্রি পাওয়ার অর্ধেক হার হবে? প্রতি 2 টি নতুন এন্ট্রির জন্য, কেবল 1 জন "অনুমোদিত" হবে? আপনার 2 মিলিয়ন সারি, এবং "অনুমোদিত" এবং "অস্বীকৃত "গুলির জন্য প্রত্যেকে 1 মিলিয়ন উদাহরণ রয়েছে, কয়েক বছর পরে আরও 10 মিলিয়ন এন্ট্রি সহ, আপনি" অনুমোদিত "এবং" অস্বীকৃত "জন্য প্রত্যেকের জন্য 6 মিলিয়ন আশা করবেন? অথবা এটি কি 1 মিলিয়ন "অগ্রহণযোগ্য" কিছুটা স্থির থাকবে, যেমন 10 মিলিয়ন নতুন এন্ট্রি সহ 11 মিলিয়ন "অনুমোদিত" এবং এখনও 1 মিলিয়ন "অগ্রহণিত" থাকবে?
রেকর্ডগুলি "অনুমোদিত" হয়ে উঠতে পারে তবে বিপরীতে নয়।
এটি আজ সত্য , তবে সময়ের সাথে সাথে জিনিসগুলি পরিবর্তিত হয় এবং তাই সবসময় এমন সম্ভাবনা থাকে যে ব্যবসাটি "অগ্রহণযোগ্য" বা "আর্কাইভ করা" ইত্যাদির মতো কিছু স্ট্যাটাসের অনুমতি দেওয়ার সিদ্ধান্ত নিতে পারে।
সুতরাং, আসুন পছন্দগুলি দেখুন:
পতাকা (বা সম্ভবত এমনকি TINYINT"স্থিতি")
- প্রতিটি স্ট্যাটাসের প্রশ্নের জন্য কিছুটা ধীর
- সময়ের সাথে আরও নমনীয় / তৃতীয় রাষ্ট্রের মতো পরিবর্তনকে অন্তর্ভুক্ত করা সহজ (যেমন "আর্কাইভ করা") কেবলমাত্র একটি নতুন লুকআপ স্থিতির মান সহ। কোনও নতুন টেবিল (অগত্যা), কিছু নতুন কোড, কেবলমাত্র কিছু কোড আপডেট হয়েছে।
- কম কাজ (যেমন কোড, পরীক্ষা ইত্যাদি) এবং একক
TINYINTকলাম আপডেট করার ক্ষেত্রে ত্রুটির জন্য কম ঘর
- কম জটিল = সময়ের সাথে কম রক্ষণাবেক্ষণের ব্যয়, নতুন কর্মীদের জন্য স্বল্প প্রশিক্ষণের সময় নির্ধারণ করা
- (সম্ভবত) লেনদেনের লগের ক্ষুদ্রতর প্রভাব যেমন একটি টেবিল আপডেট করা হয়
- দুটি টেবিলের মধ্যে "রেকর্ডস্ট্যাটাস" এবং এফকে জন্য কেবল একটি সন্ধানের টেবিলের প্রয়োজন।
দুটি পৃথক সারণী (একটি "অনুমোদিত", একটি "অনুমোদিত নয়" এর জন্য)
- প্রতিটি স্ট্যাটাসের প্রশ্নের জন্য কিছুটা দ্রুত
- সময়ের সাথে তত কম নমনীয় / তৃতীয় রাষ্ট্রের (যেমন "আর্কাইভ করা") এর মতো পরিবর্তন অন্তর্ভুক্ত করা আরও কঠিন; নতুন রাষ্ট্রের সম্ভবত আরও একটি সারণী এবং অবশ্যই নতুন এবং আপডেট হওয়া কোডের প্রয়োজন হবে would
- "অগ্রহণযোগ্য" টেবিল থেকে "অনুমোদিত" সারণিতে রেকর্ড সরানোর ক্ষেত্রে ততোধিক কাজের জন্য আরও কাজ (যেমন কোড, টেস্টিং ইত্যাদি) এবং আরও বেশি ঘর
- সময়ের সাথে আরও জটিল = আরও বেশি রক্ষণাবেক্ষণের ব্যয়, নতুন কর্মীদের জন্য এটির জন্য আরও দীর্ঘ প্রশিক্ষণের সময়
- (সম্ভবত) লেনদেনের বৃহত্তর প্রভাব হিসাবে একটি সারণী মুছে ফেলা হয় এবং একটি সন্নিবেশ করা হয়
- "সম্পর্কে চিন্তা করার কোন প্রয়োজন আইটেমের আইডি নবায়ন ": অননুমোদিত টেবিল আইডি কলাম একটি যে হয়েছে
IDENTITYকলাম, এবং অনুমোদিত টেবিল আইডি কলাম যে হয়েছে না একটি IDENTITY(যেমন সেখানে প্রয়োজন হয় না)। সুতরাং আইডি মানগুলি টেবিলের মধ্যে রেকর্ড চলার সাথে সামঞ্জস্য থাকে।
ব্যক্তিগতভাবে, আমি StatusIDকলাম দিয়ে একক টেবিলের দিকে ঝুঁকতে শুরু করব। দুটি টেবিল ব্যবহার করা অত্যধিক জটিল, অকাল অপ্টিমাইজেশনের মতো মনে হয়। এই ধরণের অপ্টিমাইজেশানটি আলোচনা করা যেতে পারে যদি / যখন রেকর্ডের সংখ্যা কয়েক শ মিলিয়নতে থাকে এবং সূচকগুলি কোনও কার্যকারিতা লাভ সরবরাহ করে না।