MySQL-এ আপনি কীভাবে data type বেছে নেন, এবং সাধারণ সমস্যাগুলো কী কী?

Question

IT Interview Practice · Accepted Answer

এমন **সবচেয়ে ছোট type বেছে নিন যা সঠিকভাবে প্রতিটি মান ধারণ করে** যা আপনি কখনো সংরক্ষণ করবেন। সঠিক type disk বাঁচায়, index ছোট করে, এবং নীরব data corruption প্রতিরোধ করে।

## সংখ্যা

- বেশিরভাগ id-র জন্য `INT` (4 bytes); `BIGINT` (8 bytes) কেবল তখনই যখন আপনি সত্যিই ~2.1 বিলিয়ন ছাড়িয়ে যান।
- টাকার জন্য `DECIMAL(10,2)` — **কখনোই** `FLOAT`/`DOUBLE` নয়, যা binary-তে round করে এবং cent হারায়।

## String

- সীমাবদ্ধ text (নাম, email)-এর জন্য `VARCHAR(n)`; `n` হলো একটি সীমা, storage কেবল যতটুকু আপনি ব্যবহার করেন।
- বড় blob (article)-এর জন্য `TEXT` — এটি off-page সংরক্ষিত হয় এবং **কোনো default থাকতে পারে না**; আপনি যে ছোট মানগুলোর উপর filter করেন সেগুলোর জন্য এটি ব্যবহার করবেন না।

## তারিখ

- `DATETIME` (কোনো timezone নেই, 8 bytes) বনাম `TIMESTAMP` (UTC-তে রূপান্তরিত, 4 bytes, ~2038 সীমা)।

```sql
CREATE TABLE payments (
  id          BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
  amount      DECIMAL(10,2) NOT NULL,   -- exact money, not FLOAT
  currency    CHAR(3)       NOT NULL,   -- always 3 chars -> fixed CHAR
  note        VARCHAR(255),             -- bounded, indexable
  created_at  DATETIME      NOT NULL DEFAULT CURRENT_TIMESTAMP
);

-- Pitfall: the default SQL mode rejects bad values (good) --
INSERT INTO payments (amount) VALUES ('abc');  -- ERROR 1366, not silently 0
```

## সাধারণ সমস্যা

- টাকার জন্য `FLOAT` ব্যবহার করা।
- অভ্যাসবশত সর্বত্র `VARCHAR(255)` — অতিরিক্ত বড় key index ফুলিয়ে দেয়।
- তারিখকে string হিসেবে সংরক্ষণ করা, যা range query ও sorting নষ্ট করে।
- কখনো negative না হওয়া id/count-এ `UNSIGNED` ভুলে যাওয়া (positive range দ্বিগুণ করে)।

## এটি কেন গুরুত্বপূর্ণ

Data type হলো সবচেয়ে সস্তা correctness ও performance সিদ্ধান্ত যা আপনি নেন, এবং পরে পরিবর্তন করা সবচেয়ে কঠিন — সংকীর্ণ, নির্ভুল type index ছোট রাখে এবং খারাপ ডেটা production bug হওয়ার আগেই দরজায় থামিয়ে দেয়।

সংখ্যা

String

তারিখ

সাধারণ সমস্যা

এটি কেন গুরুত্বপূর্ণ

সম্পর্কিত প্রশ্ন