JDBC আর ডেটাবেস — SQL, PreparedStatement আর transaction

১ · ফাইল থেকে ডেটাবেস — কেন দরকার

পর্ব ৩৭-এ ফাইলে লেখা শিখেছেন, পর্ব ৩৯-এ JSON. ছোট একটি টুলের সেটিং বা একজনের খরচের হিসাব রাখতে এগুলোই যথেষ্ট। কিন্তু একটি অনলাইন দোকান ভাবুন — শত শত ক্রেতা একসাথে অর্ডার দিচ্ছেন, স্টক কমছে, পেমেন্ট আসছে। এখানে সাধারণ ফাইল তিন জায়গায় হার মানে:

এই তিনটি সমস্যা সমাধানের জন্যই ডেটাবেস. ডেটাবেস আলাদা একটি প্রোগ্রাম (server), যা ডেটা ডিস্কে রাখে, অনেক client-এর অনুরোধ একসাথে সামলায়, আর crash-এর পরও ডেটা ঠিক রাখে। প্রোগ্রাম বন্ধ হলেও ডেটা টিকে থাকে — একে বলে persistence. আপনার Java প্রোগ্রাম সেই server-এর সাথে কথা বলে একটি ভাষায়, যার নাম SQL.

ডেটাবেস অনেক ধরনের, তবে ব্যবসার বেশিরভাগ ডেটা — অর্ডার, লেনদেন, ক্রেতা — রাখা হয় relational database-এ: PostgreSQL, MySQL, Oracle, SQL Server, আর ছোট কাজে SQLite. এগুলোর সাথে Java কথা বলে JDBC (Java Database Connectivity) দিয়ে — JDK-র java.sql package-এর কয়েকটি interface, যা প্রতিটি ডেটাবেসের জন্য একই। প্রতিটি ডেটাবেস কোম্পানি একটি JDBC driver দেয়, যা সেই interface-গুলো implement করে আর নিজের ডেটাবেসের নেটওয়ার্ক-ভাষায় অনুবাদ করে। অর্থাৎ পর্ব ২১-এর “interface দিয়ে চুক্তি, implementation বদলানো যায়” নীতির সবচেয়ে বড় বাস্তব উদাহরণ এটি।

২ · relational মডেল — টেবিল, সারি, কলাম আর key

relational ডেটাবেসে প্রতিটি ধরনের জিনিসের জন্য একটি টেবিল: ক্রেতাদের একটি, অর্ডারের একটি। টেবিলের প্রতিটি কলাম একটি বৈশিষ্ট্য (নাম, ফোন), আর প্রতিটি সারি (row) একটি জিনিস — একজন ক্রেতা। Java-র ভাষায়: টেবিল ≈ class, কলাম ≈ field, সারি ≈ object — কিন্তু মিলটা পুরোপুরি নয়, সেই গল্প ভাবনার প্রশ্নে।

customers                                    orders
┌────┬────────┬─────────────┬──────────┐     ┌─────┬─────────────┬───────┐
│ id │ name   │ phone       │ district │     │ id  │ customer_id │ total │
├────┼────────┼─────────────┼──────────┤     ├─────┼─────────────┼───────┤
│ 1  │ রহিম   │ 01711000001 │ ঢাকা     │ ◄── │ 101 │ 1           │ 1200  │
│ 2  │ করিম   │ 01811000002 │ রাজশাহী  │ ◄┐  │ 102 │ 1           │  800  │
│ 3  │ সুমি   │ 01911000003 │ ঢাকা     │  └─ │ 103 │ 2           │ 1500  │
└────┴────────┴─────────────┴──────────┘     │ 104 │ 3           │  500  │
  ▲ primary key                              └─────┴─────────────┴───────┘
                                                     ▲ foreign key → customers.id

• Primary key: যে কলাম প্রতিটি সারিকে আলাদা করে চেনায় — এখানে id. দুটি সারির একই primary key থাকতে পারে না, আর এটি কখনো খালি (NULL) নয়। ফোন নম্বরও আলাদা, কিন্তু মানুষ নম্বর বদলান; তাই সাধারণত অর্থহীন একটি সংখ্যা primary key হয়।
• Foreign key: অন্য টেবিলের primary key-র দিকে নির্দেশ — orders.customer_id → customers.id. ডেটাবেস নিশ্চিত করে যে ৯৯ নম্বর ক্রেতা না থাকলে তার নামে অর্ডার ঢোকানো যাবে না।
• Schema: কোন টেবিল, কোন কলাম, কোন টাইপ, কোন নিয়ম — ডেটার কাঠামোর পুরো নকশা। JSON ফাইলে যেকোনো কিছু লেখা যায়; ডেটাবেস schema-র বাইরে কিছু নেয় না।

ক্রেতার নাম প্রতিটি অর্ডারে না লিখে আলাদা টেবিলে একবার রাখার এই রীতিকে বলে normalization. লাভ: তথ্য এক জায়গায়, তাই পরস্পরবিরোধী কপি তৈরি হয় না। দাম: অর্ডারের সাথে নাম দেখাতে দুটি টেবিল জুড়তে হয় — পরের অংশের JOIN.

৩ · দরকারি SQL — তৈরি, ঢোকানো, খোঁজা, জোড়া, গোনা

SQL একটি declarative ভাষা: আপনি বলেন কী চান, ডেটাবেস নিজে ঠিক করে কীভাবে আনবে — অনেকটা পর্ব ৩৫-এর Stream-এর মতো। প্রথমে টেবিল তৈরি (নিচের SQL-গুলো অনলাইন runner-এ চলে না; PostgreSQL বা H2-তে চলবে):

CREATE TABLE customers (
    id        BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name      VARCHAR(100) NOT NULL,
    phone     VARCHAR(15)  NOT NULL UNIQUE,
    district  VARCHAR(50)  NOT NULL
);

CREATE TABLE orders (
    id           BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    customer_id  BIGINT NOT NULL REFERENCES customers(id),
    total        BIGINT NOT NULL CHECK (total >= 0)    -- টাকা, পূর্ণসংখ্যায়
);

GENERATED ALWAYS AS IDENTITY মানে id ডেটাবেস নিজে দেবে (MySQL-এ একই কাজ AUTO_INCREMENT). NOT NULL, UNIQUE, CHECK, REFERENCES — এগুলো নিয়ম, যা Java কোডে ভুল থাকলেও ডেটাবেস নিজে পাহারা দেয়। টাকা কখনো FLOAT/DOUBLE-এ রাখবেন না; পূর্ণসংখ্যা বা DECIMAL (Java-তে long বা BigDecimal, পর্ব ০৬)।

-- ঢোকানো (Create)
INSERT INTO customers (name, phone, district) VALUES ('রহিম', '01711000001', 'ঢাকা');

-- খোঁজা (Read): কোন সারি (WHERE), কোন কলাম, কোন ক্রমে (ORDER BY)
SELECT name, phone FROM customers WHERE district = 'ঢাকা' ORDER BY name;

-- জোড়া: প্রতিটি বড় অর্ডারের পাশে ক্রেতার নাম
SELECT o.id, c.name, o.total
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.total >= 1000;

-- বদলানো (Update) আর মোছা (Delete) — WHERE ভুলবেন না!
UPDATE customers SET district = 'খুলনা' WHERE id = 3;
DELETE FROM orders WHERE id = 104;

এই চারটি কাজকে একসাথে বলে CRUD — Create, Read, Update, Delete; প্রায় প্রতিটি ব্যবসায়িক অ্যাপের মূল কাঠামো। JOIN দুটি টেবিলের সারি মেলায় শর্ত অনুযায়ী (c.id = o.customer_id); ওপরের উদাহরণে ফল দুটি সারি: 101 | রহিম | 1200 আর 103 | করিম | 1500.

রিপোর্ট — জেলাভিত্তিক বিক্রি

ব্যবস্থাপক জানতে চান কোন জেলা থেকে কত অর্ডার আর কত টাকার বিক্রি। এখানে লাগে aggregate function (COUNT, SUM, AVG, MAX) আর GROUP BY, যা একই জেলার সারিগুলোকে এক দলে এনে প্রতিটি দলের জন্য একটি ফল দেয়:

SELECT c.district, COUNT(o.id) AS orders, SUM(o.total) AS total
FROM orders o
JOIN customers c ON c.id = o.customer_id
GROUP BY c.district
ORDER BY total DESC;

 district | orders | total
----------+--------+-------
 ঢাকা     |      3 |  2500
 রাজশাহী  |      1 |  1500

ঢাকার তিনটি অর্ডার: রহিমের দুটি (১২০০ + ৮০০) আর সুমির একটি (৫০০)। একই হিসাব Java-তে করতে হলে সব অর্ডার মেমরিতে এনে Stream-এ groupingBy লাগত; ডেটাবেসে করলে নেটওয়ার্কে আসে মাত্র দুটি সারি। নিয়ম: ছাঁকা, জোড়া আর গোনার কাজ ডেটাবেসেই করান, Java-তে আনুন শুধু যা দেখাতে হবে।

৪ · JDBC-র পথ — driver, Connection, PreparedStatement, ResultSet

JDBC-তে চারটি মূল interface, প্রতিটি আগেরটি থেকে তৈরি হয়:

driver আর connection URL

কোন ডেটাবেসে যাবেন, তা বলে JDBC URL: jdbc:postgresql://localhost:5432/shop (PostgreSQL), jdbc:mysql://localhost:3306/shop (MySQL), jdbc:sqlite:shop.db (SQLite), আর টেস্টের জন্য মেমরিতে চলা jdbc:h2:mem:shop (H2). URL-এর দ্বিতীয় অংশ দেখে DriverManager classpath-এ থাকা driver-গুলোর মধ্যে মানানসইটি বেছে নেয়। driver আসে Maven dependency হিসেবে (পর্ব ৪৬):

<dependency>
    <groupId>org.postgresql</groupId>
    <artifactId>postgresql</artifactId>
    <version>42.7.4</version>
    <scope>runtime</scope>
</dependency>

runtime scope কেন? আপনার কোড শুধু java.sql-এর interface চেনে; driver-এর কোনো class নাম লেখে না। compile-এর সময় driver লাগে না, চলার সময় লাগে। driver না থাকলে কী হয়, তা অনলাইন runner-এই যাচাই করা যায় — সেখানে JDK-র java.sql আছে, কিন্তু কোনো driver নেই:

java.sql.SQLException: No suitable driver found for jdbc:h2:mem:shop

এর getSQLState() ফেরত দেয় 08001 — “connection স্থাপন করা যায়নি” শ্রেণির কোড। বাস্তবে এই বার্তা দেখলে প্রায় সবসময় কারণ দুটির একটি: driver dependency নেই, অথবা URL-এ বানান ভুল (jdbc:postgres://, যেখানে হওয়া উচিত jdbc:postgresql://)। পুরোনো টিউটোরিয়ালে দেখবেন Class.forName("org.postgresql.Driver") — JDBC 4.0 (Java 6) থেকে driver নিজেই নিবন্ধিত হয়, এই লাইন আর লাগে না।

একটি query-র পুরো যাত্রা

ফোন নম্বর দিয়ে একজন ক্রেতা খোঁজা — JDBC-র প্রতিটি ধাপ ধরে:

Java ──TCP──► PostgreSQL :5432
ব্যবহারকারী আর পাসওয়ার্ড যাচাই, সেশন তৈরি
নতুন সংযোগে কয়েক মিলিসেকেন্ড বা তারও বেশি লাগে

SELECT id, name, phone, district
FROM customers WHERE phone = ?
SQL-এর কাঠামো স্থির — ? শুধু একটি মানের জায়গা

parameter 1 = "01811000002"
index শুরু 1 থেকে, 0 নয়
মান SQL-এর লেখায় জোড়া হয় না, আলাদা যায়

SQL + parameter ──► ডেটাবেস
ডেটাবেস plan বানায়, phone-এর index দিয়ে খোঁজে
ফল ফেরত আসে, cursor থাকে প্রথম সারির আগে

rs.next() → true   cursor সারি ১-এ
  id=2, name=করিম, phone=01811000002, district=রাজশাহী
rs.next() → false  আর সারি নেই

new Customer(rs.getLong("id"), rs.getString("name"),
             rs.getString("phone"), rs.getString("district"))
→ Customer[id=2, name=করিম, ...]

rs.close()   ← শেষে খোলা, আগে বন্ধ
ps.close()
con.close()  ← pool থাকলে আসলে ফেরত দেওয়া

stepper-এর পুরো কোড একটি method-এ। নিচের কোডের জন্য একটি সত্যিকারের ডেটাবেস আর driver লাগে, তাই এখানে চালানো যাবে না:

public Optional<Customer> findByPhone(String phone) {
    String sql = "SELECT id, name, phone, district FROM customers WHERE phone = ?";
    try (Connection con = dataSource.getConnection();
         PreparedStatement ps = con.prepareStatement(sql)) {
        ps.setString(1, phone);
        try (ResultSet rs = ps.executeQuery()) {
            if (!rs.next()) return Optional.empty();
            return Optional.of(new Customer(
                    rs.getLong("id"), rs.getString("name"),
                    rs.getString("phone"), rs.getString("district")));
        }
    } catch (SQLException e) {
        throw new DataAccessException("findByPhone failed: " + phone, e);
    }
}

ছবি ৪৭.১-এর ডেটা থাকলে findByPhone("01811000002") দেবে Optional[Customer[id=2, name=করিম, phone=01811000002, district=রাজশাহী]], আর অচেনা নম্বরে Optional.empty — “না পাওয়া” স্বাভাবিক ফল, তাই Optional (পর্ব ৩৬), exception নয়। লক্ষ করুন SELECT * নয়, কলামের নাম আলাদা করে লেখা — টেবিলে নতুন কলাম যোগ হলেও এই কোড একই থাকবে, আর অপ্রয়োজনীয় ডেটা নেটওয়ার্কে আসবে না। SQLException একটি checked exception; এখানে তাকে নিজের unchecked exception-এ cause সহ মুড়ে দেওয়া হয়েছে — পর্ব ২৯-এর exception chaining.

৫ · SQL injection — যখন ইনপুট নির্দেশ হয়ে যায়

JDBC-তে PreparedStatement-এর একটি পুরোনো ভাই আছে: Statement, যাকে পুরো SQL একটি String হিসেবে দিতে হয়। নতুনরা (আর AI) তাই লেখেন "... WHERE phone = '" + phone + "'". দেখতে নিরীহ। কিন্তু এখানে ব্যবহারকারীর লেখা সরাসরি SQL-এর অংশ হয়ে যাচ্ছে — আর ব্যবহারকারী যদি এমন কিছু লেখেন যা SQL-এর অর্থ বদলে দেয়? এই দুর্বলতার নাম SQL injection. নিচের প্রোগ্রাম কোনো ডেটাবেসে যায় না; শুধু দেখায় দুই পদ্ধতিতে ডেটাবেসের কাছে কী লেখা পৌঁছাত:

import java.util.List;

record Query(String sql, List<Object> params) {}

class Main {
    // ✗ ইনপুট সরাসরি SQL লেখার ভেতরে জোড়া
    static String unsafe(String phone) {
        return "SELECT id, name FROM customers WHERE phone = '" + phone + "'";
    }
    // ✓ SQL-এর কাঠামো স্থির, ইনপুট যায় আলাদা তালিকায়
    static Query safe(String phone) {
        return new Query("SELECT id, name FROM customers WHERE phone = ?", List.of(phone));
    }
    public static void main(String[] args) {
        for (String input : List.of("01711000001", "' OR '1'='1")) {
            System.out.println("ইনপুট   : " + input);
            System.out.println("জোড়া SQL: " + unsafe(input));
            Query q = safe(input);
            System.out.println("নিরাপদ  : " + q.sql());
            System.out.println("params  : " + q.params());
            System.out.println("---");
        }
    }
}

"SELECT ... WHERE phone = '" + input + "'"
ইনপুট আর কোড একই String-এ মিশে যায়
ডেটাবেস বুঝতে পারে না কোনটা কার লেখা

WHERE phone = '01711000001'
→ ১টি সারি, যেমনটা চাওয়া হয়েছিল
সব টেস্ট পাস — তাই সমস্যা চোখে পড়ে না

WHERE phone = '' OR '1'='1'
       ↑ খালি লেখা  ↑ নতুন শর্ত, সবসময় সত্য
→ সব ক্রেতার তথ্য ফেরত

SELECT ... WHERE phone = ?
ডেটাবেস এই কাঠামো আগেই পড়ে নেয়:
একটি কলাম, একটি তুলনা, একটি মানের জায়গা

parameter 1 = "' OR '1'='1"  (শুধু একটি লেখা)
phone কলামে কি ঠিক এই লেখা আছে? না
→ ০টি সারি; কাঠামো বদলানোর কোনো পথ নেই

এই দুর্বলতা নিয়ে xkcd-র ২০০৭ সালের বিখ্যাত কমিক “Exploits of a Mom”-এ এক মা ছেলের নাম রাখেন Robert'); DROP TABLE Students;--, আর স্কুলের সফটওয়্যার ছাত্রদের টেবিলই মুছে ফেলে। সেই থেকে প্রোগ্রামারদের মুখে মুখে “Little Bobby Tables”. কমিকের শেষ লাইনটাই শিক্ষা: ইনপুটকে পরিষ্কার করার চেষ্টার চেয়ে সঠিক পথ হলো ইনপুটকে কখনো কোড হতে না দেওয়া।

৬ · লেখা — executeUpdate, generated key, batch আর SQLException

INSERT, UPDATE, DELETE চালায় executeUpdate(), আর ফেরত দেয় একটি int — কয়টি সারি প্রভাবিত হলো। এই সংখ্যা উপেক্ষা করবেন না: UPDATE ... WHERE id = ? যদি 0 দেয়, তার মানে ওই id-র সারিই নেই, আর exception ছাড়াই কিছু ঘটেনি। নতুন সারির id ডেটাবেস বানালে (IDENTITY) সেটা ফেরত পেতে চাইতে হয় generated key:

public Customer save(String name, String phone, String district) {
    String sql = "INSERT INTO customers (name, phone, district) VALUES (?, ?, ?)";
    try (Connection con = dataSource.getConnection();
         PreparedStatement ps = con.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS)) {
        ps.setString(1, name);
        ps.setString(2, phone);
        ps.setString(3, district);
        ps.executeUpdate();                                   // ফেরত দেয় 1
        try (ResultSet keys = ps.getGeneratedKeys()) {
            keys.next();
            return new Customer(keys.getLong(1), name, phone, district);
        }
    } catch (SQLException e) {
        throw new DataAccessException("save failed: " + phone, e);
    }
}

batch — হাজার সারি, একবারে

একটি CSV থেকে দশ হাজার প্রোডাক্ট ঢোকাতে হবে। লুপে প্রতিবার executeUpdate() মানে দশ হাজারবার নেটওয়ার্কে যাওয়া-আসা। batch update-এ প্রতিটি সারির মান বসিয়ে addBatch(), শেষে একবার executeBatch(), যা প্রতিটি সারির ফলের একটি int[] দেয়। সাধারণত পুরো batch একটি transaction-এ রাখা হয় (পরের অংশ), যাতে মাঝপথে ব্যর্থ হলে অর্ধেক ঢোকানো ডেটা না থাকে:

con.setAutoCommit(false);
try (PreparedStatement ps = con.prepareStatement(
        "INSERT INTO products (name, price) VALUES (?, ?)")) {
    for (Product p : products) {
        ps.setString(1, p.name());
        ps.setLong(2, p.price());
        ps.addBatch();
    }
    int[] counts = ps.executeBatch();      // প্রতিটি সারির ফল
    con.commit();
} catch (SQLException e) {
    con.rollback();
    throw e;
}

SQLException আর SQLState

ডেটাবেসের প্রায় সব সমস্যা আসে SQLException হয়ে — ভুল SQL, সংযোগ বিচ্ছিন্ন, নিয়ম ভাঙা। বার্তা ডেটাবেসভেদে আলাদা, তাই কোড দিয়ে সিদ্ধান্ত নিতে চাইলে দেখুন getSQLState() — পাঁচ অক্ষরের মানসম্মত SQLState, যার প্রথম দুই অক্ষর শ্রেণি বলে:

ডেটাবেস কোম্পানির নিজস্ব সংখ্যা পাওয়া যায় getErrorCode() দিয়ে। আর একটি সুবিধা: পর্ব ২৯-এর নিয়মে SQLException নিচের স্তরেই ধরে নিজের ভাষার exception-এ রূপান্তর করুন (DuplicatePhoneException), যাতে ওপরের ব্যবসায়িক কোড SQL-এর খুঁটিনাটি না জানে। Spring ঠিক এটাই করে — সব SQLException-কে নিজের unchecked DataAccessException-পরিবারে অনুবাদ করে।

৭ · transaction — সব নয়তো কিছুই নয়

রহিম তাঁর ওয়ালেট থেকে করিমকে ১০০০ টাকা পাঠাবেন। ডেটাবেসে এটা দুটি UPDATE: রহিমের ব্যালেন্স থেকে বাদ, করিমের ব্যালেন্সে যোগ। প্রথমটি সফল হয়ে দ্বিতীয়টির আগে কিছু ভেঙে পড়লে টাকা উধাও। এখানে লাগে transaction — কয়েকটি কাজের একটি দল, যা ডেটাবেস একক হিসেবে দেখে: হয় সবগুলো স্থায়ী হবে (commit), নয়তো সবগুলো বাতিল (rollback).

JDBC-তে নতুন connection থাকে auto-commit অবস্থায়: প্রতিটি statement নিজেই একটি transaction, চলামাত্র commit. কয়েকটি statement একসাথে বাঁধতে হলে setAutoCommit(false) দিয়ে শুরু করুন:

1con.setAutoCommit(false);2try {3    debit.executeUpdate();   // রহিম -10004    credit.executeUpdate();  // করিম +10005    con.commit();6} catch (SQLException e) {7    con.rollback();8    throw e;9}

বাস্তবের পূর্ণ কোডে আরও দুটি সতর্কতা আছে: পর্যাপ্ত ব্যালেন্স যাচাই আর executeUpdate()-এর ফেরত-সংখ্যা যাচাই:

void transfer(long fromId, long toId, long amount)
        throws SQLException, InsufficientBalanceException {
    String debit  = "UPDATE wallets SET balance = balance - ? WHERE id = ? AND balance >= ?";
    String credit = "UPDATE wallets SET balance = balance + ? WHERE id = ?";
    try (Connection con = dataSource.getConnection()) {
        con.setAutoCommit(false);
        try (PreparedStatement d = con.prepareStatement(debit);
             PreparedStatement c = con.prepareStatement(credit)) {
            d.setLong(1, amount); d.setLong(2, fromId); d.setLong(3, amount);
            if (d.executeUpdate() != 1) throw new InsufficientBalanceException("wallet " + fromId);
            c.setLong(1, amount); c.setLong(2, toId);
            if (c.executeUpdate() != 1) throw new SQLException("wallet " + toId + " not found");
            con.commit();
        } catch (SQLException | InsufficientBalanceException | RuntimeException e) {
            con.rollback();
            throw e;
        }
    }
}

debit-এর WHERE ... AND balance >= ? লক্ষ করুন: ব্যালেন্স যাচাই আর বাদ দেওয়া একই statement-এ, তাই আগে SELECT করে পরে UPDATE করার মাঝের ফাঁকে অন্য কেউ ঢুকে পড়তে পারে না — পর্ব ৪০-এর check-then-act race condition এভাবে ডেটাবেসেই বন্ধ। 0 সারি বদলালে মানে ব্যালেন্স কম। (InsufficientBalanceException এখানে নিজের বানানো একটি checked exception; কোডটি চালাতে ডেটাবেস লাগবে।)

ACID — transaction-এর চারটি প্রতিশ্রুতি

চারটি একসাথে ACID. Isolation সবচেয়ে সূক্ষ্ম: পুরো কঠোর হলে ধীর, ঢিলে হলে অদ্ভুত ফল। con.setTransactionIsolation(...) দিয়ে isolation level বদলানো যায় — READ_COMMITTED (PostgreSQL-এর ডিফল্ট), REPEATABLE_READ (MySQL InnoDB-র ডিফল্ট), SERIALIZABLE (সবচেয়ে কঠোর)। শুরুতে ডিফল্ট রাখুন, আর টাকার হিসাবে ওপরের মতো শর্তসহ UPDATE লিখুন।

৮ · কোড সাজানো — Repository pattern আর connection pool

প্রতিটি ব্যবসায়িক method-এর ভেতরে SQL আর ResultSet ছড়িয়ে থাকলে কী হয়? ডেটাবেস বদলানো কঠিন, ব্যবসার নিয়ম টেস্ট করতে ডেটাবেস লাগে, আর একই SQL পাঁচ জায়গায় পাঁচভাবে লেখা। সমাধান পর্ব ৪৮-এর একটি design pattern: Repository pattern — ডেটা রাখা-আনার সব কাজ একটি interface-এর পেছনে, যা ব্যবসার ভাষায় কথা বলে (findByPhone, save), SQL-এর ভাষায় নয়। একই ধারণার পুরোনো নাম DAO (Data Access Object). নিচে interface আর একটি Map-ভিত্তিক implementation — JDBC implementation (অংশ ৪ আর ৬-এর method দুটি) ঠিক এর জায়গা নেবে, আর বাকি কোড এক অক্ষরও বদলাবে না:

import java.util.*;
record Customer(long id, String name, String phone, String district) {}
interface CustomerRepository {
    Customer save(String name, String phone, String district);
    Optional<Customer> findByPhone(String phone);
}
class InMemoryCustomerRepository implements CustomerRepository {
    private final Map<String, Customer> byPhone = new LinkedHashMap<>();
    public Customer save(String name, String phone, String district) {
        var c = new Customer(byPhone.size() + 1, name, phone, district);
        byPhone.put(phone, c);
        return c;
    }
    public Optional<Customer> findByPhone(String phone) {
        return Optional.ofNullable(byPhone.get(phone));
    }
}
class Main {
    static String register(CustomerRepository repo, String name, String phone, String district) {
        if (repo.findByPhone(phone).isPresent()) return "বাতিল: " + phone + " আগেই আছে";
        return "যোগ হলো: " + repo.save(name, phone, district);
    }
    public static void main(String[] args) {
        CustomerRepository repo = new InMemoryCustomerRepository();
        System.out.println(register(repo, "রহিম", "01711000001", "ঢাকা"));
        System.out.println(register(repo, "করিম", "01811000002", "রাজশাহী"));
        System.out.println(register(repo, "রহিমা", "01711000001", "খুলনা"));
        System.out.println(repo.findByPhone("01999999999").map(Customer::name).orElse("নেই"));
    }
}

connection pool — সংযোগ ধার নেওয়া আর ফেরত দেওয়া

প্রতিটি অনুরোধে নতুন connection খোলা মানে প্রতিবার নেটওয়ার্ক handshake, পাসওয়ার্ড যাচাই, সেশন তৈরি — query-র চেয়ে বেশি সময় যেতে পারে সংযোগেই। connection pool অ্যাপ শুরুর সময় কয়েকটি connection খুলে রাখে আর ধার দেয়। Java-তে সবচেয়ে প্রচলিত pool HikariCP, যা Spring Boot 2.0 থেকে ডিফল্ট। pool নিজেই একটি DataSource, তাই Repository-র কোড বদলায় না — এটাই DriverManager-এর বদলে DataSource নেওয়ার সুবিধা:

var config = new HikariConfig();
config.setJdbcUrl(System.getenv("DB_URL"));
config.setUsername(System.getenv("DB_USER"));
config.setPassword(System.getenv("DB_PASSWORD"));
config.setMaximumPoolSize(10);
DataSource dataSource = new HikariDataSource(config);
var repo = new JdbcCustomerRepository(dataSource);

অলস : [c1] [c2] [c3]
ব্যস্ত: —
সংযোগের খরচ একবারই, শুরুতে

অলস : [c2] [c3]
ব্যস্ত: c1 → A
নতুন সংযোগ খোলা হয়নি, শুধু ধার

অলস : —
ব্যস্ত: c1 → A, c2 → B, c3 → C

অলস : —
অপেক্ষায়: D
নির্দিষ্ট সময়ে না পেলে SQLException
(HikariCP-র connectionTimeout)

A: con.close()  → আসলে বন্ধ নয়, pool-এ ফেরত
ব্যস্ত: c1 → D, c2 → B, c3 → C

৯ · বাস্তব প্রজেক্টে — N+1, টেস্টিং, migration, নিরাপত্তা আর উচ্চস্তরের টুল

N+1 query সমস্যা

অর্ডারের তালিকা দেখাতে হবে, প্রতিটির পাশে ক্রেতার নাম। সহজ কোড:

List<Order> orders = orderRepo.findAll();                  // ১টি query
for (Order o : orders) {
    Customer c = customerRepo.findById(o.customerId());     // প্রতিটি অর্ডারে আরও ১টি
    System.out.println(o.id() + " " + c.name());
}

১০০টি অর্ডার হলে ডেটাবেসে যায় ১০১টি query — একে বলে N+1 query problem. নিজের ল্যাপটপে ১০টি অর্ডারে টের পাবেন না; production-এ দশ হাজার অর্ডারে পেজ খুলতে কয়েক সেকেন্ড। সমাধান অংশ ৩-এর JOIN — একটি query-তে অর্ডার আর নাম একসাথে — অথবা সব customerId নিয়ে একবার WHERE id IN (...). পর্ব ৫১-এ দেখবেন ORM-এ এই সমস্যা আরও লুকিয়ে আসে, কারণ সেখানে order.getCustomer() দেখতে সাধারণ getter, কিন্তু ভেতরে চুপচাপ query চালাতে পারে।

টেস্টিং আর migration

Repository-র JDBC implementation-ও টেস্ট করতে হবে — SQL-এ বানান ভুল তো compiler ধরে না। দুটি প্রচলিত পথ: H2-র মতো in-memory database (jdbc:h2:mem:test), যা টেস্ট শুরুতে তৈরি হয় আর শেষে মুছে যায়; অথবা Testcontainers, যা Docker-এ সত্যিকারের PostgreSQL চালিয়ে টেস্ট করে। H2 দ্রুত, কিন্তু SQL-এর খুঁটিনাটি PostgreSQL-এর সাথে পুরো মেলে না; Testcontainers ধীর, কিন্তু production-এর মতো — পর্ব ৪৭-এর JUnit দিয়েই দুটি চালানো যায়।

schema-ও কোডের মতো বদলায় — নতুন কলাম, নতুন টেবিল। হাতে হাতে প্রতিটি server-এ ALTER TABLE চালালে কোথায় কোন সংস্করণ, কেউ জানে না। database migration টুল — Flyway বা Liquibase — এই বদলগুলোকে ক্রমিক ফাইলে রাখে (V1__create_customers.sql, V2__add_orders.sql), git-এ কোডের সাথে, আর অ্যাপ শুরুর সময় যেগুলো এখনো চলেনি শুধু সেগুলো চালায়। কোনটা চলেছে তা Flyway নিজের একটি টেবিলে লিখে রাখে।

নিরাপত্তা — credential আর অনুমতি

• পাসওয়ার্ড কোডে নয়: "jdbc:...", "root", "123456" git-এ গেলে চিরকালের জন্য ফাঁস। URL, ব্যবহারকারী, পাসওয়ার্ড পড়ুন environment variable বা secret manager থেকে, যেমন ওপরের System.getenv("DB_PASSWORD").
• লগে নয়: config বা JDBC URL লগ করবেন না — কিছু URL-এ পাসওয়ার্ড থাকে (?password=...)। exception-এর বার্তায়ও নয়।
• ন্যূনতম অনুমতি: least privilege — অ্যাপের ডেটাবেস ব্যবহারকারী শুধু নিজের টেবিলে SELECT/INSERT/UPDATE/DELETE পাবে; DROP বা অন্যের টেবিলে নয়, আর কখনো root/postgres superuser নয়। migration চালাতে আলাদা ব্যবহারকারী। তাহলে কোথাও injection ফাঁক থেকে গেলেও ক্ষতি সীমিত।

JDBC-র ওপরের স্তর — কোনটা কখন

কাঁচা JDBC-তে একটি SELECT-এর জন্য দশ-পনেরো লাইন লাগে। তাই বাস্তবে প্রায় সবাই এর ওপরে কোনো স্তর ব্যবহার করেন — কিন্তু সবগুলোর নিচে JDBC-ই চলে, তাই এই পর্বের ধারণাগুলো সবখানে কাজে লাগবে:

Spring Framework 6.1-এ আসা JdbcClient দিয়ে অংশ ৪-এর পুরো method প্রায় এক লাইনে নেমে আসে — ?, resource বন্ধ, আর record-এ রূপান্তর সব নিজে করে:

List<Customer> dhaka = jdbcClient
        .sql("SELECT id, name, phone, district FROM customers WHERE district = ?")
        .param("ঢাকা")
        .query(Customer.class)
        .list();

Spring Boot কীভাবে এই jdbcClient আর DataSource নিজে বানিয়ে আপনার class-এ দিয়ে দেয় (dependency injection), তা পর্ব ৫০-এ; JPA আর Hibernate-এর প্রথম দেখা পর্ব ৫১-এর REST API-তে।

১০ · AI-এর যুগে — AI-এর লেখা ডেটাবেস কোড রিভিউ করুন

AI-কে “Java দিয়ে ডেটাবেস থেকে ইউজার খোঁজার কোড লেখো” বললে প্রায়ই যা আসে, তা চলে — আর এই পর্বের প্রায় প্রতিটি নিয়ম ভাঙে। কারণ ইন্টারনেটের পুরোনো টিউটোরিয়ালে এভাবেই লেখা, আর AI সেগুলো থেকেই শিখেছে। নিচের ভুলগুলো চিনে রাখুন:

AI-এর কোড হাতে পেলে — যাচাইয়ের চেকলিস্ট

• কোথাও + দিয়ে ইনপুট SQL-এ জোড়া হয়নি; টেবিল/কলামের নাম বাইরে থেকে এলে allow-list আছে
• প্রতিটি Connection, Statement, ResultSet try-with-resources-এ
• একসাথে হতে হবে এমন বদলগুলো এক transaction-এ, catch-এ rollback সহ
• executeUpdate()-এর ফেরত-সংখ্যা যাচাই করা হয়েছে যেখানে তা গুরুত্বপূর্ণ
• কোডে বা লগে কোনো পাসওয়ার্ড নেই; ডেটাবেস ব্যবহারকারী superuser নয়
• SELECT * নেই, লুপের ভেতরে query নেই
• SQLException গিলে ফেলা হয়নি — cause সহ অর্থপূর্ণ exception-এ রূপান্তর
• একটি ছোট H2 বা Testcontainers টেস্টে আসল SQL অন্তত একবার চালানো হয়েছে