প্রতিটি কলামের জন্য আপনি যে টাইপ বেছে নেন তা শুধু সঠিকতার বিষয় নয় — এটি সরাসরি একটি মেমরি আর স্টোরেজ সিদ্ধান্ত। বেশি বড় কলাম জায়গা নষ্ট করে আর সেটি স্পর্শ করা প্রতিটি ইনডেক্সকে ধীর করে দেয়; কম বড় কলাম প্রোডাকশনে সত্যিকারের তথ্য কেটে ফেলে। এই পাঠে আপনি নির্দিষ্ট টাইপ আর সীমা পাবেন যা বেছে নেওয়া উচিত।
পূর্ণসংখ্যা আর দশমিক সংখ্যা, 1 বাইট থেকে 8+ বাইট পর্যন্ত আকারের, আপনার আসলে যে সীমা প্রয়োজন তার উপর নির্ভর করে।
TINYINT · SMALLINT · INT · BIGINT · DECIMAL(p,s) · FLOAT/DOUBLECREATE TABLE Product (
id BIGINT UNSIGNED PRIMARY KEY,
stock_count SMALLINT UNSIGNED,
price DECIMAL(10,2)
);সাধারণ ভুল
দুটোই টেক্সট জমা রাখে — CHAR নির্দিষ্ট-দৈর্ঘ্যের আর প্যাডেড, VARCHAR পরিবর্তনশীল-দৈর্ঘ্যের আর আপনি যা লেখেন শুধু তাই প্লাস একটি ছোট দৈর্ঘ্য প্রিফিক্স জমা রাখে।
CHAR(n) — সবসময় n বাইট ব্যবহার করে
VARCHAR(n) — প্রকৃত দৈর্ঘ্য + 1–2 বাইট ওভারহেড ব্যবহার করেCREATE TABLE Employee (
country_code CHAR(2),
full_name VARCHAR(100),
email VARCHAR(254)
);সাধারণ ভুল
পরিবর্তনশীল-দৈর্ঘ্যের টেক্সটের জন্য CHAR ব্যবহার করা, প্রতিটি ছোট মানের জন্য প্যাডিং-এ জায়গা নষ্ট করা।
ক্যালেন্ডার তারিখ, টাইমস্ট্যাম্প, আর সময়কালের জন্য বিশেষভাবে তৈরি টাইপ — তারিখকে টেক্সট হিসেবে জমা রাখার চেয়ে ছোট আর নিরাপদ।
DATE (3 বাইট) · TIME (3 বাইট) · DATETIME (8 বাইট) · TIMESTAMP (4 বাইট)CREATE TABLE Employee (
hire_date DATE,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);সাধারণ ভুল
তারিখকে VARCHAR হিসেবে জমা রাখা, যা সর্টিং, রেঞ্জ কোয়েরি, আর তারিখ গণনা সম্পূর্ণভাবে ভেঙে দেয়।
নির্দিষ্ট ছোট পছন্দ আর আধা-কাঠামোগত তথ্যের জন্য টাইপ, সারিকে কমপ্যাক্ট আর কোয়েরিযোগ্য রাখতে সীমিতভাবে ব্যবহার করা হয়।
CREATE TABLE Employee (
is_active BOOLEAN DEFAULT TRUE,
status ENUM('active','on_leave','terminated'),
metadata JSON
);সাধারণ ভুল
"নমনীয়" বলে সঠিক কলামের বদলে JSON ব্যবহার করা, যা সাধারণ কোয়েরি ধীর আর ইনডেক্স করা কঠিন করে তোলে।
প্রায় প্রতিটি প্রোডাকশন স্কিমায় থাকা ফিল্ডের জন্য নির্দিষ্ট টাইপ আর সীমা — "এই কলামটি আসলে কী হওয়া উচিত" প্রশ্নের সরাসরি উত্তর।
| ফিল্ড | সুপারিশকৃত টাইপ | কারণ |
|---|---|---|
| full_name | VARCHAR(100) | 30 প্রকৃত নাম কেটে ফেলে — অনেক নাম মিডল নেম/টাইটেলসহ 40–80+ অক্ষর হয় |
| first_name / last_name | প্রতিটি VARCHAR(50) | আলাদা রাখলে স্বাধীনভাবে সর্ট, গ্রিট, আর ভ্যালিডেট করা যায় |
| VARCHAR(254) | একটি বৈধ ইমেইল ঠিকানার জন্য RFC 5321-এর কঠোর সীমা | |
| password_hash | CHAR(60) | bcrypt আউটপুট সবসময় ঠিক 60 অক্ষর — CHAR প্যাডিং অপচয় এড়ায় |
| phone | VARCHAR(20) | "+", দেশের কোড, এক্সটেনশন কভার করে — কখনো INT হিসেবে জমা রাখবেন না |
| uuid | CHAR(36) বা BINARY(16) | পড়া-যায় এমন টেক্সট রূপের জন্য 36, 2x+ ছোট ইনডেক্সের জন্য 16 বাইনারি |
| postal_code | VARCHAR(10) | আন্তর্জাতিক কোড ভিন্ন হয়; কিছু অক্ষরও ধারণ করে |
| country_code | CHAR(2) | নির্দিষ্ট-প্রস্থের ISO 3166-1 alpha-2 |
| currency_amount | DECIMAL(19,4) | সঠিক নির্ভুলতা, বড় অঙ্ক আর 4 দশমিক স্থানের জন্য জায়গা |
| url | VARCHAR(2048) | একটি URL-এর জন্য ব্যবহারিক ব্রাউজার-প্রয়োগকৃত ঊর্ধ্বসীমা |
| ip_address | VARBINARY(16) বা VARCHAR(45) | 16 বাইট বাইনারি IPv4 + IPv6 কমপ্যাক্টভাবে কভার করে |
| is_active | BOOLEAN | একটি TINYINT বা VARCHAR ফ্ল্যাগের বদলে 1 বাইট |
একটি সাধারণ বাস্তব-জগতের বাগ: full_name VARCHAR(30) সাইজ করা — "Priyanka Chattopadhyay" বা "Jean-Baptiste van der Berg"-এর মতো নাম ইতিমধ্যেই 30 অক্ষর ছাড়িয়ে যায়। যেহেতু VARCHAR শুধু যা ব্যবহৃত হয় তার খরচ নেয়, VARCHAR(30)-এর বদলে VARCHAR(100) সাইজ করলে ছোট নামের জন্য কার্যত কোনো মেমরি খরচ বাড়ে না — সীমাটি শুধু বিরল লম্বা নামের ক্ষেত্রেই গুরুত্বপূর্ণ।
সাধারণ নিয়ম
সবচেয়ে ছোট নির্দিষ্ট টাইপ বেছে নিন যা কখনো বৈধভাবে ওভারফ্লো করবে না (আইডি, কোড, ফ্ল্যাগ), আর VARCHAR সীমার ক্ষেত্রে উদার হোন যেহেতু এগুলো আগে থেকে জায়গা সংরক্ষণ করে না।
সাধারণ ভুল
শুধু প্রতিটি কলামের জন্য টাইপ বেছে নেওয়ার বাইরেও, একটি স্কিমাকে বড় স্কেলে সংক্ষিপ্ত রাখার কয়েকটি নিয়ম।
সঠিক টাইপ আর আকার প্রতিষ্ঠিত হওয়ার পর, পরের চারটি পাঠে প্রতিটি SQL পরিবার একে একে আলোচনা করা হবে, শুরু হবে DDL দিয়ে — সেই কমান্ড যা আপনি এইমাত্র সাইজ করতে শেখা টেবিলগুলো আসলে তৈরি করে।