TINYINT কখন INT ব্যবহার করবেন?


91

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

উদাহরণস্বরূপ, tinyintআপনি যখন জানবেন যে কেবলমাত্র আপনি যে ডেটা সংরক্ষণ করবেন তা হ'ল 1, 0 বা নাল (পরে এটি 2 বা 3 এ প্রসারিত করার খুব ছোট সুযোগ সহ) use

তবে, আমি এটি করার একমাত্র কারণটি হ'ল স্টোরেজ উদ্দেশ্যে - 4 বাইটের পরিবর্তে এক সারি 1 বাইট ব্যবহার করা।

আপনার হার্ড ড্রাইভে স্থান বাঁচানো বাদ দিয়ে শুধু tinyint(বা smallintবা এমনকি bigint) ব্যবহারের প্রভাবগুলি কী কী int?


2
এটি খুব সুন্দর একটি ক্যুইসিটন (+1)। মাইএসকিউএলএর নির্বাচন করুন ... প্রক্রিয়া বিশ্লেষণ () যা টেবিলটি প্রদত্ত নির্বাচনের জন্য থাকা উচিত সবচেয়ে ক্ষুদ্রতম ডাটা টাইপের প্রস্তাব দেয়। আংশিকভাবে আমার উত্তর পিছনে অনুপ্রেরণা ছিল।
রোল্যান্ডোমাইএসকিউএলডিবিএ

3
সূক্ষ্ম প্রশ্ন, তবে সংক্ষিপ্তসার পরিসীমা 0-255। বিট ক্ষেত্রটি 0 বা 1 (বা NULL)। টিনিনেন্টের জন্য স্টোরেজ ব্যয় 1 বাইট। একটি টেবিলের প্রতি 8 বিট ক্ষেত্রের জন্য স্টোরেজ 1 বাইট লাগবে। msdn.microsoft.com/en-us/library/ms187745.aspx এবং msdn.microsoft.com/en-us/library/ms177603.aspx
billinkc

@ বিলিংক রাইট এ কারণেই আমি কলামটি 2 বা 3 এর মান অন্তর্ভুক্ত করার সম্ভাবনাটি উল্লেখ করেছি যদি আপনি 2 বা 3 অন্তর্ভুক্ত করেন তবে আপনাকে টিনিনেন্ট ব্যবহার করতে হবে (খুব ক্ষুদ্রতম স্কেলে)।
রিচার্ড

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

2
@ ইউজার 656565 S I'd use an ENUM for such a thing.এসকিউএল সার্ভারে নেই, আপনি এটি করবেন না, কারণ এতে কোনও ধরণের সংখ্যা নেই।
আন্ডারস্কোর_২

উত্তর:


92

ডিস্ক স্পেস সস্তা ... এটি বিন্দু নয়!

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

ওভাররাইডিং বার্তাটি ডিজাইনের বিষয়। আপনি ভিএলডিবি অঞ্চলে আঘাত না করা পর্যন্ত যথাযথভাবে সুনির্দিষ্ট সার্ভারে পৃথক ডাটাবেসে পার্থক্য দেখা যাবে না তবে আপনি যদি কিছু বাইট সংরক্ষণ করতে পারেন তবে কেন তা করবেন না।

আমি আগের একটি প্রশ্নে বর্ণিত পরিবেশের কথা মনে করিয়ে দিচ্ছি । 400+ ডাটাবেসগুলি, প্রতিটি এসকিউএল উদাহরণ হিসাবে 50mb-50GB থেকে আকারের। যে পরিবেশে জুড়ে রেকর্ড প্রতি টেবিল প্রতি ডাটাবেস কয়েক বাইট স্ক্রাব করা একটি উল্লেখযোগ্য পার্থক্য করতে পারে।


29

অন্যান্য উত্তর ছাড়াও ...

সারি এবং সূচী এন্ট্রি 8k পৃষ্ঠায় সংরক্ষণ করা হয়। সুতরাং প্রতি সারিতে 3 বাইটে এক মিলিয়ন সারি ডিস্কে 3 এমবি নয়: এটি প্রতি পৃষ্ঠার সারিগুলির সংখ্যাকে প্রভাবিত করে ("পৃষ্ঠা ঘনত্ব")।

একইটি এনভারচার থেকে বারচর, ছোট্ট তারিখ থেকে ডেটটাইম, ইনট টিনিনেন্ট ইত্যাদির ক্ষেত্রে প্রযোজ্য

সম্পাদনা করুন, জুন 2013

http://sqlblog.com/blogs/joe_chang/archive/2013/06/16/load-test-manifesto.aspx

এই নিবন্ধে বলা হয়েছে

গুরুত্বপূর্ণ মানদণ্ডগুলি হ'ল কার্ডিনালিটি এবং পৃষ্ঠা থেকে সারি অনুপাত।

সুতরাং, ডেটা টাইপ পছন্দ পছন্দ করে


5
ভাল যুক্তি. আপনি যে কলামটিতে যুক্ত করতে চান তা সম্পূর্ণরূপে নির্ধারিত দৈর্ঘ্যের কলামগুলির সমন্বয়ে 4028 বাইট সারি হওয়া একটি নিখুঁত খারাপ উদাহরণ case একটি ছোটখাট সংযোজন আপনাকে 4030 (প্রতি পৃষ্ঠায় 2 সারি) নিয়ে যেতে পারে তবে কোনও অন্তর্নিহিত স্থান আপনাকে সীমানা ছাড়িয়ে যায় (প্রতি পৃষ্ঠায় 1 সারি, প্রতি পৃষ্ঠায় 4028 বাইট নষ্ট করে)।
মার্ক স্টোর-স্মিথ

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

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

14

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

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

তবুও, যদি সূচকের এন্ট্রিগুলিতে যৌগিক এন্ট্রি থাকে এবং সমস্তগুলি পূর্ণসংখ্যার হয়, বাইরের দিক দিয়ে যত ছোট ছোট পূর্ণসংখ্যা হয় তত ভাল এবং তত দ্রুত হয়।


13

ডাটাবেসগুলি বড় হওয়ার সাথে সাথে সমস্ত জিনিসই জটিলতা হয়ে ওঠে:

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

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

আপনি যদি জানেন যে একটি টেবিলের কয়েকটি কলামগুলিতে কয়েক মিলিয়ন সারি বা এমন একটি ছোট টেবিল থাকবে যা এফকে'কে বহু মিলিয়ন-সারি করে দেবে, যার জন্য তাদের ডেটা সংরক্ষণের জন্য 4 বাইটের পূর্ণসংখ্যার প্রয়োজন হয় না, তবে একটি 2 বাইট যথেষ্ট - ছোট ব্যবহার করুন । 0-255 সীমাতে মানগুলি যদি যথেষ্ট হয় তবে TINYINT । একটি হ্যাঁ / কোনও পতাকা নেই? আছে বিআইটি


9

কিছুদিনের জন্য tinyintবনাম intএমন ডিস্কের স্থান, পৃষ্ঠা টুকরা এবং রক্ষণাবেক্ষণ সময় হিসাবে স্পষ্ট পার্থক্য আছে, সেখানে এই সব কারণে হবে না varchar

সুতরাং কেন এটি সমস্ত পাঠ্য ক্ষেত্র হিসাবে ঘোষণা করবেন না varchar(4000), যেহেতু এটি যেভাবে কেবল প্রয়োজনীয় স্থানটি ব্যবহার করবে? আরও বেশি আপনাকে গ্যারান্টি দেওয়া হবে যে আপনার ডেটা কখনই কাটা যাবে না।

উত্তর অবশ্যই:

  1. আপনার উদ্দেশ্যগুলির স্পষ্টতা (কারণ নামের ক্ষেত্রটি 4000 বর্ণের হওয়া উচিত তা কেউ বুঝতে পারবে না)
  2. আপনি যেমন যাচাই করতে চান তা নিশ্চিত করতে চান যে নাম হিসাবে কোনও পুরো জীবনী প্রবেশ করে না।

এই খুব একই কারণে প্রযোজ্য tinyint


3
এটি একটি পুরানো থ্রেড, তবে স্পষ্টকরণ এবং বৈধতা একমাত্র কারণ নয়। যদি আপনার কাছে VARCHAR (20) হওয়া উচিত এমন কোনও কিছুর জন্য ভ্রচার (4000) থাকে তবে ক্যোয়ারী প্ল্যানটি মনে করবে যে আপনার মেমরি এবং সিপিইউ প্রয়োজনীয়তাগুলি সেই কলামটির ক্ষেত্রে যা হওয়া উচিত তার বহুগুণ। আমি এটি করার জন্য সময় নিইনি, তবে আমি অনুমান করছি যে আপনি সম্ভবত ভিচারার (২০) এর জন্য একটি ক্যোয়ারী পরিকল্পনাটি দেখে এবং তারপরে ভিচারার (৪০০০) এ পরিবর্তন করতে পারেন এবং আনুমানিক ব্যয় পরীক্ষা করতে পারেন।

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