ORM-এর ধারণা — object আর table, query builder বনাম raw SQL

১ · দুই জগতের অমিল — object আর table

বাজারঘরের API এতদিন চলেছে ছোট SQLite ফাইল আর হাতে লেখা query-তে। এবার সত্যিকারের ডেটাবেসের পালা। SQL কীভাবে লিখতে হয়, সেটি DBMS ও SQL কোর্সের কাজ, আর ORM-এর ভেতরের session ও unit of work আছে ORM আর migration পর্বে। এখানে আমাদের প্রশ্ন ব্যবহারিক: একটি TypeScript অ্যাপে কোন স্তরে কাজ করবেন, আর তার দাম কত।

আপনার কোডে একটি পণ্য হলো object: তার ভেতরে নাম, দাম, আর তার ক্যাটাগরি। ডেটাবেসে একই পণ্য products table-এর একটি সারি, আর ক্যাটাগরি আছে আলাদা table-এ, foreign key দিয়ে জোড়া। এই অমিলের নাম impedance mismatch.

নিচের ছোট প্রোগ্রামটি ORM-এর দুই দিকের কাজ হাতে করে। একটি JOIN-এর চ্যাপ্টা সারি থেকে object বানায়, আর object বদলালে শুধু বদলানো ঘরের UPDATE তৈরি করে। এটি শেখানোর মডেল, আসল ORM নয়।

// Flat rows from one JOIN: snake_case, the category repeats on every row.
const rows = [
  { id: 17, name: 'Chola dal', price: 120, stock: 12, category_id: 2, category_name: 'Dal' },
  { id: 1, name: 'Mosur dal', price: 145, stock: 0, category_id: 2, category_name: 'Dal' },
];

class Category { constructor(id, name) { this.id = id; this.name = name; } }
class Product {
  constructor(r, category) {
    Object.assign(this, { id: r.id, name: r.name, price: r.price, stock: r.stock, category });
  }
  inStock() { return this.stock > 0; }
}

function mapRows(list) {
  const seen = new Map();        // one Category object per primary key
  return list.map((r) => {
    if (!seen.has(r.category_id)) seen.set(r.category_id, new Category(r.category_id, r.category_name));
    return new Product(r, seen.get(r.category_id));
  });
}

function dirtySql(before, now) { // object back to a table: only what changed
  const changed = ['name', 'price', 'stock'].filter((k) => before[k] !== now[k]);
  const set = changed.map((k, i) => `${k} = $${i + 1}`).join(', ');
  return { sql: `UPDATE products SET ${set} WHERE id = $${changed.length + 1}`,
           params: [...changed.map((k) => now[k]), now.id] };
}

const [a, b] = mapRows(rows);
console.log(a.name, a.category.name, 'inStock:', a.inStock());
console.log('same Category object:', a.category === b.category);
const before = { ...b };
b.stock = 30;
console.log(dirtySql(before, b));

Chola dal Dal inStock: true
same Category object: true
{
  sql: 'UPDATE products SET stock = $1 WHERE id = $2',
  params: [ 30, 1 ]
}

২ · তিন স্তর — একই “বাজারঘর” query চারভাবে

অ্যাপ থেকে ডেটাবেসে যাওয়ার পথ মোটামুটি তিনটি স্তরে ভাগ করা যায়। সবচেয়ে নিচে database driver, যেমন pg. আপনি raw SQL লেখেন, driver পাঠায়। তার ওপরে query builder, যেমন Kysely. এটি কোডের method থেকে SQL বানায়। সবচেয়ে ওপরে ORM, যেমন Prisma: আপনি কী চান বলেন, সে SQL আর সম্পর্ক দুটিই সামলায়।

এবার একটি বাস্তব কাজ: “ডাল ক্যাটাগরির, স্টকে আছে এমন, সবচেয়ে সস্তা ৩টি পণ্য, ক্যাটাগরির নামসহ।” ডেটাবেস আসল PostgreSQL 18.6, npm-এর embedded-postgres দিয়ে চালানো, যাতে কিছু install করতে না হয়। ১০,০০০টি পণ্য, ৮টি ক্যাটাগরি।

const r = await pool.query(
  `SELECT p.id, p.name, p.price, c.name AS category
     FROM products p JOIN categories c ON c.id = p.category_id
    WHERE c.slug = $1 AND p.stock > $2
    ORDER BY p.price, p.id LIMIT $3`, ['dal', 0, 3]);

const rows = await db.selectFrom('products as p')
  .innerJoin('categories as c', 'c.id', 'p.category_id')
  .select(['p.id', 'p.name', 'p.price', 'c.name as category'])
  .where('c.slug', '=', 'dal').where('p.stock', '>', 0)
  .orderBy('p.price').orderBy('p.id').limit(3).execute();

const rows = await db
  .select({ id: products.id, name: products.name,
            price: products.price, category: categories.name })
  .from(products)
  .innerJoin(categories, eq(categories.id, products.categoryId))
  .where(and(eq(categories.slug, 'dal'), gt(products.stock, 0)))
  .orderBy(asc(products.price), asc(products.id)).limit(3);

const rows = await prisma.product.findMany({
  where: { category: { slug: 'dal' }, stock: { gt: 0 } },
  select: { id: true, name: true, price: true,
            category: { select: { name: true } } },
  orderBy: [{ price: 'asc' }, { id: 'asc' }],
  take: 3,
});

চারটি একই প্রথম সারি দিল। Prisma-র ফলে শুধু ক্যাটাগরি object-এর ভেতরে, কারণ ORM সম্পর্ককে সম্পর্কের মতোই রাখে:

সত্যিকারের run · PostgreSQL 18.6 · ~/bazarghar · আউটপুট ছাঁটা, শেষের সংখ্যা মোট সারি · npm-এর latest তখন Prisma 8.0.0-rc.29, তাই stable 7.10.1 ব্যবহার হয়েছে

pg       {"id":17,"name":"ছোলার ডাল","price":120,"category":"ডাল"} 3
kysely   {"id":17,"name":"ছোলার ডাল","price":120,"category":"ডাল"} 3
drizzle  {"id":17,"name":"ছোলার ডাল","price":120,"category":"ডাল"} 3
prisma   {"id":17,"name":"ছোলার ডাল","price":120,"category":{"name":"ডাল"}} 3

খেসারি ডাল ১১০ টাকায় সবচেয়ে সস্তা হলেও আসেনি, কারণ তার স্টক ০. (এই তুলনার ল্যাবে সরলতার জন্য price পূর্ণ টাকায় রাখা হয়েছে। বাজারঘরের আসল চুক্তিতে টাকা পূর্ণসংখ্যা পয়সায়, পর্ব ৩২-এর মতো।) ফল এক, কিন্তু ডেটাবেসে কী গেল? প্রতিটি tool-এ log চালু করলে উত্তর মেলে। পড়ার সুবিধার জন্য লাইন ভেঙে ও ছেঁটে দেখানো হলো।

সত্যিকারের run · তিনটি tool-এর নিজের query log · লাইন ভাঙা ও ছাঁটা

kysely:  select "p"."id", "p"."name", "p"."price", "c"."name" as "category"
         from "products" as "p" inner join "categories" as "c" on "c"."id" = "p"."category_id"
         where "c"."slug" = $1 and "p"."stock" > $2 order by "p"."price", "p"."id" limit $3
         [ 'dal', 0, 3 ]

drizzle: select "products"."id", "products"."name", "products"."price", "categories"."name"
         from "products" inner join "categories" on "categories"."id" = "products"."category_id"
         where ("categories"."slug" = $1 and "products"."stock" > $2)
         order by "products"."price" asc, "products"."id" asc limit $3 -- params: ["dal", 0, 3]

prisma:  SELECT … "products"."id", … "products"."category_id" FROM "public"."products"
         LEFT JOIN "public"."categories" AS "j0" ON ("j0"."id") = ("public"."products"."category_id")
         WHERE (("j0"."slug" = $1 AND ("j0"."id" IS NOT NULL)) AND "public"."products"."stock" > $2)
         ORDER BY … LIMIT $3 OFFSET $4   ["dal",0,"3","0"]
prisma:  SELECT "public"."categories"."id", "public"."categories"."name"
         FROM "public"."categories" WHERE "public"."categories"."id" IN ($1,$2,$3) OFFSET $4   [2,2,2,"0"]

Kysely আর Drizzle-এর SQL প্রায় হাতে লেখা SQL-এর মতোই। Prisma 7.10.1 এখানে দুটি query পাঠাল: প্রথমটি পণ্য আনে, দ্বিতীয়টি ক্যাটাগরি, আর শেষে কোডে দুই ফল জোড়া দেওয়া হয়। IN-এ একই 2 তিনবার এসেছে, সেটিও log-এই দেখা গেল। এটি ভুল নয়, Prisma-র কৌশল। নিচের স্টেপারে এই যাত্রার প্রতিটি ধাপ দেখুন।

1const rows = await prisma.product.findMany({2  where: { category: { slug: 'dal' }, stock: { gt: 0 } },3  select: { id: true, name: true, price: true,4            category: { select: { name: true } } },5  orderBy: [{ price: 'asc' }, { id: 'asc' }], take: 3,6});7console.log(rows[0].category.name);

Drizzle নিয়ে একটি কথা। ওপরে তার SQL-ধাঁচের API দেখলেন, যা query builder-এর খুব কাছে। তার একটি relational API-ও আছে (db.query.products.findMany), যা run-এ একটি LEFT JOIN LATERAL পাঠিয়েছে। তাই Drizzle-কে ORM বলা হবে না query builder, সেটি মতের ব্যাপার। স্তরগুলো কঠিন দেয়াল নয়, একটি ঢাল।

Query builder ভেতরে খুব জটিল কিছু নয়। নিচে একটি ছোট শেখানোর মডেল আছে, যা দেখায় মূল কাজ দুটি: নাম যাচাই করা, আর মান params-এ আলাদা রাখা।

// A teaching model of a query builder. Use a real one in real projects.
const OPS = new Set(['=', '>', '<', '>=', '<=']);
function id(name) {               // names cannot be parameters, so check them
  if (!/^[a-z_][a-z0-9_]*$/.test(name)) throw new Error(`bad name: ${name}`);
  return `"${name}"`;
}

class Query {
  constructor(state) { this.s = state; }
  with(patch) { return new Query({ ...this.s, ...patch }); } // never mutates
  select(...cols) { return this.with({ cols: cols.map(id) }); }
  where(col, op, value) {
    if (!OPS.has(op)) throw new Error(`bad operator: ${op}`);
    const n = this.s.params.length + 1;
    return this.with({
      wheres: [...this.s.wheres, `${id(col)} ${op} $${n}`],
      params: [...this.s.params, value],
    });
  }
  compile() {
    const { table, cols, wheres, params } = this.s;
    const where = wheres.length ? ` WHERE ${wheres.join(' AND ')}` : '';
    return { sql: `SELECT ${cols.join(', ')} FROM ${id(table)}${where}`, params };
  }
}
const from = (table) =>
  new Query({ table, cols: ['*'], wheres: [], params: [] });

const base = from('products').select('id', 'name').where('stock', '>', 0);
console.log(base.where('price', '<', 200).compile());
console.log(base.compile());
console.log(from('products').where('name', '=', "x' OR '1'='1").compile());
try { from('products').where('price; DROP', '=', 1); }
catch (e) { console.log('refused:', e.message); }

{
  sql: 'SELECT "id", "name" FROM "products" WHERE "stock" > $1 AND "price" < $2',
  params: [ 0, 200 ]
}
{
  sql: 'SELECT "id", "name" FROM "products" WHERE "stock" > $1',
  params: [ 0 ]
}
{
  sql: 'SELECT * FROM "products" WHERE "name" = $1',
  params: [ "x' OR '1'='1" ]
}
refused: bad name: price; DROP

৩ · Parameter আর SQL injection

ফর্মে খালি ঘর পূরণের কথা ভাবুন। ব্যাংকের চেকে “টাকার পরিমাণ” ঘরে যা-ই লেখা হোক, ব্যাংক সেটিকে পরিমাণ হিসেবেই পড়ে, নতুন নির্দেশ হিসেবে নয়। Parameterized query ঠিক এই ঘর। SQL-এর গঠন আগে যায়, মান আলাদা যায়। আর string জোড়া দেওয়া মানে নিজের হাতে পুরো চেকটিই ব্যবহারকারীকে লিখতে দেওয়া। তখন ঘটে SQL injection: ইনপুটের অংশ SQL-এর আদেশ হয়ে যায়।

প্রতিরক্ষার দিক থেকে ব্যাপারটি বোঝার জন্য নিচে একটি নকল executor আছে, কোনো আসল ডেটাবেস নয়। এটি দেখায়, ডেটাবেস লেখাটিকে টুকরো করার পরে কী দেখে।

// A mock executor, not a database. It shows how text becomes structure.
// It understands only: SELECT slug FROM t WHERE a = b [OR a = b]
const table = ['chal', 'dal', 'tel', 'mosla'];

function tokenize(sql) {
  return sql.match(/'[^']*'|\$\d+|[A-Za-z]+|=/g);
}

function run(sql, params = []) {
  const tokens = tokenize(sql);
  const clause = tokens.slice(tokens.indexOf('WHERE') + 1);
  const value = (t, slug) => t === 'slug' ? slug
    : t.startsWith('$') ? params[Number(t.slice(1)) - 1]
    : t.slice(1, -1);                     // a quoted literal
  const rows = table.filter((slug) => {
    for (let i = 0; i < clause.length; i += 4) {
      if (value(clause[i], slug) === value(clause[i + 2], slug)) return true;
    }
    return false;
  });
  return { clause: clause.join(' '), rows };
}

const input = "x' OR '1'='1";

console.log('concatenated:', run(`SELECT slug FROM t WHERE slug = '${input}'`));
console.log('parameter   :', run('SELECT slug FROM t WHERE slug = $1', [input]));
console.log('normal value:', run('SELECT slug FROM t WHERE slug = $1', ['dal']));

concatenated: {
  clause: "slug = 'x' OR '1' = '1'",
  rows: [ 'chal', 'dal', 'tel', 'mosla' ]
}
parameter   : { clause: 'slug = $1', rows: [] }
normal value: { clause: 'slug = $1', rows: [ 'dal' ] }

একই ঘটনা আসল PostgreSQL-এ, শুধু আমাদের ৮টি ক্যাটাগরির সাধারণ table-এ:

সত্যিকারের run · PostgreSQL 18.6 · pg 8.23.1 · local ল্যাব · ইনপুট x' OR '1'='1

concatenated: { n: 8 }
parameter   : { n: 0 }

Query builder আর ORM-এ মান সাধারণভাবে নিজে থেকেই parameter-এ যায়, এটি তাদের বড় সুবিধা। কিন্তু দুটি জায়গায় সুরক্ষা থাকে না। প্রথমত, কলাম বা table-এর নাম parameter হতে পারে না, যা পর্ব ৩৪-এর ORDER BY ফাঁদে দেখেছেন। দ্বিতীয়ত, raw SQL-এর “unsafe” পথে। আক্রমণের ধরন আর পূর্ণ প্রতিরক্ষা আছে Injection প্রতিরক্ষা পর্বে। এখানে একটি নিয়মই যথেষ্ট: মান parameter-এ, নাম allowlist থেকে।

৪ · Connection pool — ধার করা সংযোগ

ডেটাবেসের সংযোগ বানানো দামি। PostgreSQL প্রতিটি সংযোগের জন্য আলাদা একটি process চালায়, আর শুরুতে পরিচয় যাচাই লাগে। একই কম্পিউটারে একটি run-এ মাপা ফল:

সত্যিকারের run · একটি local কম্পিউটারে একবার · SELECT 1-এর মধ্যমা · 127.0.0.1

new connection each time: 21.32 ms   pooled: 0.054 ms

প্রায় ৪০০ গুণ পার্থক্য, আর এখানে network-ই নেই। তাই অ্যাপ connection pool রাখে। রেস্তোরাঁর কথা ভাবুন: প্রতিটি অর্ডারের জন্য নতুন ওয়েটার নিয়োগ করলে সময় নষ্ট হয়। পাঁচজন ওয়েটার থাকেন, অর্ডার নেন, কাজ শেষে আবার ফাঁকা হন। সবাই ব্যস্ত থাকলে নতুন অর্ডার সারিতে দাঁড়ায়। pg-এর Pool-এ ডিফল্ট max ১০. Prisma 7-এর pg adapter-ও একই pool ব্যবহার করে, আর সেখানেও ডিফল্ট ১০.

এবার চাপ দেওয়া যাক। ২টি সংযোগের pool, আর একসাথে এলো ৫টি request, প্রতিটির query ১০০ ms.

এখন আসল সংখ্যা। ২০টি query, প্রতিটি pg_sleep(0.1), একসাথে পাঠানো। হিসাবের সূত্র ⌈N / max⌉ × s, যেখানে N query-র সংখ্যা, s একটির সময়।

সত্যিকারের run · একটি local কম্পিউটারে একবার · pg 8.23.1 · ঘুমের query, তাই ডেটাবেসে আসল চাপ নেই

মাপা সময় সূত্রের চেয়ে বেশি, কারণ সংযোগ খুলতেও সময় লাগে আর প্রতি query-তে ছোট বাড়তি খরচ আছে। max=20-এ অপেক্ষার ৭৫ ms পুরোটাই একসাথে ২০টি সংযোগ খোলার সময়। তাহলে কি pool বড় রাখাই ভালো? এখানে হ্যাঁ, কারণ pg_sleep CPU খায় না। আসল query CPU আর disk নিয়ে লড়ে, তাই একটি সীমার পরে বেশি সংযোগ গতি কমায়। ২ নম্বর ভাবনার প্রশ্নে এর হিসাব আছে।

Pool-এর দুটি error চিনে রাখুন। দুটিই run থেকে:

সত্যিকারের run · max: 2, connectionTimeoutMillis: 300 · দুটি connect(), কোনো release() নেই

after two connect() with no release: total=2 idle=0
error: timeout exceeded when trying to connect

এই বার্তা দেখে অনেকে ভাবেন ডেটাবেস বন্ধ। আসলে এটি pool-এর সারিতে অপেক্ষার timeout. আগে দেখুন কোথাও release() বাদ পড়েছে কি না। pool.query() নিজেই নেয় আর ফেরত দেয়, তাই সেটিই সহজ পথ। pool.connect() লিখলে finally-তে release() রাখুন।

Serverless কেন pool ফুরিয়ে ফেলে

একটি Express server-এ একটি pool, সংখ্যাটি আপনার হাতে। Serverless-এ ভিড় বাড়লে platform কোডের অনেক কপি চালায়। প্রতিটি কপিতে আলাদা Node process, তাই আলাদা pool. Prisma-র docs-ও বলছে, প্রতিটি function নিজের client আর নিজের pool রাখে। ডেটাবেসের সীমা কিন্তু একটিই। নিচে ২৫টি পর্যন্ত “কপি” আলাদা pool দিয়ে নকল করা হলো, প্রতিটি max: 5. PostgreSQL-এর ডিফল্ট max_connections ১০০.

সত্যিকারের run · একটি local কম্পিউটারে একবার · প্রতিটি কপিতে আলাদা Pool, একই process-এ নকল করা · error-এর লাইন আলাদা করে সাজানো

max_connections 100  superuser_reserved 3
instances= 5 pool=5 wanted= 25 ok= 25 failed=  0 open-after=26
instances=10 pool=5 wanted= 50 ok= 50 failed=  0 open-after=51
instances=15 pool=5 wanted= 75 ok= 75 failed=  0 open-after=76
instances=25 pool=5 wanted=125 ok= 99 failed= 26 open-after=100
53300 sorry, too many clients already

১২৫টি চাওয়া, ৯৯টি পেল, ১টি ছিল মাপার নিজের সংযোগ, মোট ১০০. বাকি ২৬টি query সরাসরি ব্যর্থ। এখানে superuser দিয়ে চালানো হয়েছে। সাধারণ user হলে সংরক্ষিত ৩টি বাদে ৯৭টিতেই থামত। লক্ষ করুন open-after: কাজ শেষেও সংযোগ খোলা থাকে। Serverless কপি ঘুমিয়ে থাকলেও তার সংযোগ কিছু সময় জায়গা আটকে রাখতে পারে।

সমাধান সাধারণত তিন ধরনের। প্রতিটি কপিতে pool ছোট রাখা (max ১ বা ২, সংখ্যাটি বিতর্কিত, নিজের চাপে মেপে নিন)। মাঝে একটি connection pooler রাখা, যেমন PgBouncer, যা Prisma-র docs-ও serverless-এর জন্য বলে। অথবা provider-এর HTTP-ভিত্তিক driver, যদি থাকে। আরেকটি সহজ ভুল: request handler-এর ভেতরে new PrismaClient() লেখা। এতে প্রতি request-এ একটি নতুন pool হয়। Client একবার module-এর ওপরের স্তরে বানান। পর্ব ২৯-এর repository স্তরে এটি রাখা সহজ।

৫ · Active Record বনাম Data Mapper

ORM-এর দুটি বড় নকশার নাম আসে Martin Fowler-এর ২০০২ সালের Patterns of Enterprise Application Architecture বই থেকে। তত্ত্বটি ORM আর migration পর্বে আছে। মূল প্রশ্ন একটিই: ডেটাবেসে কে লিখবে? চায়ের দোকানে হিসাব দোকানি নিজের হাতে রাখেন, নাকি আলাদা একজন হিসাবরক্ষক?

TypeORM দুটিকেই সমর্থন করে, তাই পাশাপাশি দেখা সহজ। TypeScript-এর পুরোনো ও পরিচিত এই ORM-টি এখানে শুধু তুলনার জন্য। লেখার সময়ে ১.১.২ দিয়ে চালানো:

// Active Record: the object saves itself
const c = await Category.findOneByOrFail({ slug: 'dal' });
c.name = 'ডাল ও শস্য';
await c.save();

// Data Mapper: a repository saves the object
const repo = dataSource.getRepository(Category);
const d = await repo.findOneByOrFail({ slug: 'dal' });
d.name = 'ডাল';
await repo.save(d);

সত্যিকারের run · TypeORM 1.1.2 · PostgreSQL 18.6 · c.save()-এর SQL, ছাঁটা · repo.save(d)-তেও একই গঠন এসেছে

SELECT "Category"."id" AS "Category_id", … FROM "categories" "Category" WHERE "Category"."id" = $1  [2]
START TRANSACTION
UPDATE "categories" SET "name" = $1 WHERE "id" = $2  ["ডাল ও শস্য",2]
COMMIT

দুই পথের SQL হুবহু এক ধরনের। পার্থক্যটি কোডের গঠনে, ডেটাবেসে নয়। আর দেখুন, save() শুধু একটি UPDATE নয়: আগে একটি বাড়তি SELECT, তারপর transaction. একটি ছোট শব্দের পেছনে চারটি বিনিময়। লুপে ১,০০০ বার save() ডাকলে এর দাম কত হবে, ভাবুন।

Prisma কোন দিকে? Prisma-র docs নিজেকে Data Mapper ধারার বলে, তবে সাধারণ ORM থেকে আলাদা: কোনো entity class নেই, ফল সাধারণ object, আর সব কাজ prisma.product-এর মতো client দিয়ে। পর্ব ৬৮-তে Django আর পর্ব ৭০-এ Laravel-এর Eloquent-এ Active Record ধাঁচ দেখবেন। ছোট CRUD অ্যাপে Active Record দ্রুত। নিয়ম-ভারী ব্যবসায় Data Mapper পরে কম কষ্ট দেয়। কোনোটিই সর্বজয়ী নয়।

৬ · Type safety — কে কী দেয়

TypeScript-এর আসল সুবিধা হলো ভুল চালানোর আগেই ধরা (পর্ব ০৬). কিন্তু ডেটাবেস TypeScript-এর বাইরের জগৎ। প্রতিটি tool এই দূরত্ব ভিন্নভাবে পূরণ করে। একটি ফাইলে ইচ্ছা করে একই ভুল করা হলো: price-এর জায়গায় pirce.

// pg, no generic: rows are any
const a = await pool.query('SELECT id, price FROM products');
console.log(a.rows[0].pirce);                                   // line 15

// pg, with a generic: we promise a shape, nothing checks it
const b = await pool.query<{ id: number; discount: number }>(
  'SELECT id, price FROM products');
console.log(b.rows[0].discount);                                // line 19

await k.selectFrom('products').select('pirce').execute();       // line 22
await k.selectFrom('products').selectAll()
  .where('price', '=', 'cheap').execute();                      // line 25
await d.select().from(products).where(eq(products.pirce, 100)); // line 28
await prisma.product.findMany({ where: { pirce: 100 } });       // line 31

const row = await prisma.product.findFirstOrThrow({ select: { id: true, name: true } });
console.log(row.price);                                         // line 35

সত্যিকারের run · tsc 6.0.3, strict · বার্তা ছাঁটা

t.ts(22,39): error TS2769: No overload matches this call.
  … Argument of type '"pirce"' is not assignable to parameter of type 'SelectExpression<DB, "products">'.
t.ts(25,64): error TS2345: Argument of type '"cheap"' is not assignable to parameter of type
  'OperandValueExpressionOrList<DB, "products", "price">'.
t.ts(28,51): error TS2551: Property 'pirce' does not exist on type 'PgTableWithColumns<…>'. Did you mean 'price'?
t.ts(31,42): error TS2561: Object literal may only specify known properties, but 'pirce' does not
  exist in type 'ProductWhereInput'. Did you mean to write 'price'?
t.ts(35,17): error TS2339: Property 'price' does not exist on type '{ id: number; name: string; }'.

লাইন ১৫ আর ১৯-এর কোনো error নেই। চালালে দুটিই নীরবে undefined. Run-এ এসেছে typo at runtime: undefined. প্রথমটি any. দ্বিতীয়টি আরও সূক্ষ্ম: { discount: number } একটি প্রতিশ্রুতি, যাচাই নয়। এই ধরনের type assertion-এ compiler আপনাকে বিশ্বাস করে। আর লাইন ৩৫ সবচেয়ে সুন্দর: Prisma select দেখে ফলের type-ও ছোট করে নিল।

৭ · ORM যা লুকায়, আর কখন raw SQL-এ নামবেন

ORM-এর আরাম আর বিপদ একই জায়গায়: SQL চোখের আড়ালে। তাই নিয়ম হলো, development-এ log চালু রাখুন। Prisma-য় এটি কয়েক লাইনের কাজ:

import { PrismaPg } from '@prisma/adapter-pg';
import { PrismaClient } from './generated/prisma/client.ts';

export const prisma = new PrismaClient({
  adapter: new PrismaPg({ connectionString: process.env.DATABASE_URL, max: 10 }),
  log: [{ emit: 'event', level: 'query' }],
});

prisma.$on('query', (e) => {
  console.log(e.query, e.params, `${e.duration.toFixed(1)}ms`);
});

এভাবেই ২ নম্বর অংশের দুটি query ধরা পড়েছে। Prisma 7.10.1-এ relationJoins নামের preview feature চালু করে relationLoadStrategy: 'join' লিখলে একই কাজ একটি query-তে হয়েছে:

সত্যিকারের run · Prisma 7.10.1, relationJoins preview · ছাঁটা · নতুন version-এ এই আচরণ বদলাতে পারে, নিজের version-এর docs দেখুন

SELECT "t0"."id", "t0"."name", "t0"."price", "t0"."category_id" AS "categoryId",
       "Product_category"."__prisma_data__" AS "category"
FROM "public"."products" AS "t0"
LEFT JOIN "public"."categories" AS "j1" ON ("j1"."id") = ("t0"."category_id")
LEFT JOIN LATERAL (SELECT JSONB_BUILD_OBJECT('name', "t2"."name") AS "__prisma_data__" …
WHERE … LIMIT $4   ["1","dal",0,"3"]

ORM যে SQL পাঠায়, আপনি নিজেও সেটি পড়তে ও চালাতে পারেন। নিচের live ব্লকে একই কাজ SQLite-এর বানানে: Prisma-র দুই ধাপ, তারপর হাতের একটি JOIN, আর শেষে তার plan. Query বদলে দেখতে পারেন।

-- Step 1: the products (what Prisma's first query does)
SELECT p.id, p.name, p.price, p.category_id
FROM products p
LEFT JOIN categories j0 ON j0.id = p.category_id
WHERE j0.slug = 'dal' AND p.stock > 0
ORDER BY p.price, p.id LIMIT 3 OFFSET 0;

-- Step 2: the categories of those rows
SELECT id, name FROM categories WHERE id IN (2, 2, 2);

-- By hand: one JOIN gives everything at once
SELECT p.id, p.name, p.price, c.name AS category
FROM products p
JOIN categories c ON c.id = p.category_id
WHERE c.slug = 'dal' AND p.stock > 0
ORDER BY p.price, p.id LIMIT 3;

EXPLAIN QUERY PLAN
SELECT p.id, p.name, p.price, c.name AS category
FROM products p
JOIN categories c ON c.id = p.category_id
WHERE c.slug = 'dal' AND p.stock > 0
ORDER BY p.price, p.id LIMIT 3;

কখন raw SQL

ORM-এ সব কাজ করতে হবে, এমন কোনো নিয়ম নেই। ধরুন বাজারঘরের মালিক চান, “paid অর্ডারে প্রতিটি ক্যাটাগরির সবচেয়ে বেশি বিক্রি হওয়া পণ্য।” এখানে window function লাগে, যা Prisma-র সাধারণ API-তে নেই। তখন $queryRaw:

const status = 'paid', limit = 3;
const rows = await prisma.$queryRaw<
  { category: string; name: string; sold: bigint }[]
>`
  SELECT * FROM (
    SELECT c.name AS category, p.name, SUM(i.qty) AS sold,
           ROW_NUMBER() OVER (PARTITION BY c.id
                              ORDER BY SUM(i.qty) DESC, p.id) AS rnk
    FROM order_items i
    JOIN orders o ON o.id = i.order_id
    JOIN products p ON p.id = i.product_id
    JOIN categories c ON c.id = p.category_id
    WHERE o.status = ${status}
    GROUP BY c.id, c.name, p.id, p.name
  ) t WHERE rnk = 1 ORDER BY sold DESC LIMIT ${limit}`;

এটি একটি tagged template. দেখতে string জোড়ার মতো, কিন্তু ${status} SQL-এ ঢোকে না। ফাংশনটি লেখার টুকরো আর মান আলাদা পায়, আর মান যায় parameter হিসেবে। Log-ই তার প্রমাণ:

সত্যিকারের run · Prisma 7.10.1 · ছাঁটা · শেষের তিনটি ফলের পাশে “←” দিয়ে তাদের log সাজিয়ে দেওয়া হয়েছে

sql: SELECT * FROM ( SELECT c.name AS category, … WHERE o.status = $1 GROUP BY … LIMIT $2  ["paid",3]
[
  { category: 'চাল', name: 'Product 16', sold: 8n, rnk: 1n },
  { category: 'চিনি', name: 'Product 4', sold: 8n, rnk: 1n },
  { category: 'মসলা', name: 'Product 11', sold: 6n, rnk: 1n }
]
JSON: Do not know how to serialize a BigInt

tagged template: [ { n: 0 } ]    ← … WHERE slug = $1  ["x' OR '1'='1"]
Unsafe + concat: [ { n: 8 } ]    ← … WHERE slug = 'x' OR '1'='1'  []

order by param: [ { id: 8 }, { id: 16 } ]    ← … ORDER BY $1 DESC  ["price"]

চারটি শিক্ষা। এক, SUM আর COUNT এখানে BigInt হয়ে এলো: 8n. তাই res.json(rows) সোজা ভেঙে পড়ে। ::int cast করুন, বা উত্তর পাঠানোর আগে Number() দিন। দুই, <{…}[]> আবার একটি প্রতিশ্রুতি, যাচাই নয়। Prisma-র TypedSQL বা Zod যাচাই এই ফাঁক কমায়। তিন, tagged template আর $queryRawUnsafe-এর ফল ০ আর ৮. নামে “Unsafe” থাকাটা ফাঁকা কথা নয়। চার, ORDER BY ${col} কোনো error দেয়নি, শুধু sort করেনি, কারণ পর্ব ৩৪-এর মতোই এটি একটি মান।

৮ · খরচ কত — মাপা overhead

“ORM ধীর”, এই কথা প্রায়ই শোনা যায়। কত ধীর, কোথায়? এবার মাপা যাক। প্রতিটি tool একই কম্পিউটারে, একই PostgreSQL-এ, ৫০০ বার গরম করে, তারপর তিন দফায় মোট ৯,০০০ বার চালানো হলো, এক সময়ে একটি করে।

সময় ms-এ · সত্যিকারের run, একটি local কম্পিউটারে একবার · 127.0.0.1 · Node.js 24.15 · ১০,০০০ সারি · মেমরিতে থাকা ডেটা · এটি সাধারণ ফল নয়, tool-এর version বদলালে সংখ্যা বদলাবে

“৩.৪ গুণ ধীর” শুনতে ভয়ংকর। কিন্তু যোগ করে দেখুন। Primary key query-তে বাড়তি সময় ০.২২৬ − ০.০৬৬ = ০.১৬ ms. ধরুন একটি পাতায় ৫টি query, আর পুরো অনুরোধের বাজেট ২০০ ms. তাহলে বাড়তি ৫ × ০.১৬ = ০.৮ ms, মানে বাজেটের ০.৪%. আর বাস্তবে ডেটাবেস অন্য কম্পিউটারে থাকলে প্রতি query-তে network-ই সাধারণত এর চেয়ে অনেক বেশি নেয়, যা এই run-এ নেই।

তবে একটি জায়গায় এই সংখ্যা গুরুত্বপূর্ণ। এই বাড়তি সময় Node-এর CPU-তে যায়, তাই event loop ব্যস্ত থাকে। এক সময়ে একটি করে চালালে ০.০৬৬ ms মানে সেকেন্ডে প্রায় ১৫,১৫০টি, আর ০.২২৬ ms মানে প্রায় ৪,৪২০টি। খুব বেশি query-র গরম পথে এটি টের পাওয়া যেতে পারে। বেশিরভাগ বাজারঘর সেখানে পৌঁছানোর অনেক আগে অন্য সমস্যায় পড়বে।

আসল বড় পার্থক্য আসে ব্যবহারের ধরনে। একই ১,০০০টি পণ্য ঢোকানো:

সত্যিকারের run · একটি local কম্পিউটারে একবার · ৫ বারের মধ্যমা · ১,০০০ সারি

pg unnest                7.0 ms
prisma createMany       54.3 ms
prisma create x1000    340.5 ms

Tool এক, কিন্তু লুপে create ডাকলে createMany-এর চেয়ে প্রায় ৬.৩ গুণ সময় লাগল। ORM-এর গতি নিয়ে তর্কের চেয়ে এই ধরনের ভুল বেশি ক্ষতি করে। N+1-ও একই জাতের সমস্যা, পর্ব ৪২-এ সেটি আসছে। আগে query-র সংখ্যা ঠিক করুন, তারপর tool নিয়ে ভাবুন।

৯ · কোনটি বেছে নেবেন — tool আর ডেটাবেস

এই তর্কে সম্প্রদায় সত্যিই বিভক্ত। কেউ বলেন SQL শিখুন, ORM বাদ দিন। কেউ বলেন CRUD হাতে লেখা সময়ের অপচয়। দুই পক্ষই নিজের প্রকল্পে সঠিক হতে পারেন। তাই নিয়ম নয়, প্রশ্ন দিয়ে এগোন।

বাস্তবে অনেক দল মিশিয়ে কাজ করে: সাধারণ কাজে ORM, রিপোর্টে raw SQL. আমরা বাজারঘরে পর্ব ৩৯ থেকে Prisma ব্যবহার করব, কারণ শেখার পথে তার schema আর migration খুব স্পষ্ট। এর মানে এই নয় যে Prisma সবার সেরা। এখন একটি query ধরে সিদ্ধান্তের ধাপগুলো দেখুন।

কোন ডেটাবেস

Tool-এর আগে ডেটাবেসের প্রশ্ন। সংক্ষেপে, আর মনে রাখবেন এগুলো সাধারণ প্রবণতা, নিয়ম নয়:

বাংলাদেশের অনেক shared hosting প্ল্যানে, সাধারণত cPanel-এর সাথে, MySQL বা MariaDB দেওয়া থাকে, আর PostgreSQL থাকতেও পারে, না-ও পারে। কেনার আগে আপনার provider-কে জিজ্ঞেস করুন। আরও তিনটি প্রশ্ন করুন: Node.js অ্যাপ দীর্ঘক্ষণ চালানো যায় কি না, প্রতি user-এর সংযোগের সীমা কত, আর ডেটাবেসে বাইরে থেকে সংযোগ করা যায় কি না। সীমা কম হলে pool-ও ছোট রাখতে হবে। Prisma-য় MySQL-এর জন্য আলাদা driver adapter লাগে (docs-এ mariadb driver), আর SQLite-এর জন্য @prisma/adapter-better-sqlite3. কোথায় চালাবেন, সেই পুরো তুলনা পর্ব ৮২-তে।

১০ · AI-এর যুগে ORM

“Prisma দিয়ে products API লিখে দাও” বললে AI দ্রুত কোড দেয়। এই জায়গায় AI-এর ভুল দুই ধরনের: পুরোনো API, আর চলে এমন কিন্তু বিপজ্জনক কোড। Prisma-র version দ্রুত বদলায়, তাই পুরোনো উদাহরণের সম্ভাবনা বেশি।

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

• package.json-এ version দেখেছি, আর API সেই version-এর docs-এ মিলিয়েছি
• Query log চালিয়ে দেখেছি কয়টি SQL যায়, আর কোন কলাম আসে
• Diff-এ raw SQL খুঁজে দেখেছি, মান সবসময় parameter-এ
• Client মাত্র একবার তৈরি হচ্ছে, আর pool-এর সীমা ডেটাবেসের সীমার মধ্যে
• নকল ডেটায় চাপ দিয়ে দেখেছি, আর একটি test লিখেছি
• Connection string কোডে নেই, env থেকে আসে, আর কোনো গোপন মান AI-কে দিইনি