সম্পর্ক — one-to-many, many-to-many আর শপের ডেটা মডেল

১ · সম্পর্ক মানে আসলে একটি কলাম

মুদি দোকানের খাতার কথা ভাবুন। দোকানি প্রতিটি বাকির পাশে ক্রেতার পুরো ঠিকানা লেখেন না, লেখেন খাতার পাতা নম্বর। সেই নম্বর ধরে ক্রেতার পাতায় গেলেই সব পাওয়া যায়। Database-এর সম্পর্ক ঠিক এমন। Order table-এর userId কলামে থাকে User-এর primary key. এই কলামই foreign key.

ER মডেল, cardinality আর normalization-এর তত্ত্ব DBMS কোর্সে আছে। পরিচিত না হলে ER থেকে table আর JOIN পর্ব দুটি একবার দেখে নিন। এখানে সেগুলো আবার শেখানো হবে না। এখানে দেখব Prisma সেগুলো কীভাবে লেখে, আর PostgreSQL-এ সত্যিই কী ঘটে।

model User {
  id        Int       @id @default(autoincrement())
  addresses Address[]            // one-to-many, কলাম নয়
  cart      Cart?                // one-to-one, কলাম নয়
}

model Address {
  id     Int  @id @default(autoincrement())
  userId Int                     // আসল foreign key কলাম
  user   User @relation(fields: [userId], references: [id], onDelete: Cascade)
}

model Cart {
  id     Int  @id @default(autoincrement())
  userId Int  @unique            // @unique-ই এটিকে one-to-one করে
  user   User @relation(fields: [userId], references: [id], onDelete: Cascade)
}

One-to-many আর one-to-one-এর পার্থক্য একটিমাত্র শব্দে: @unique. একজন ব্যবহারকারীর অনেক ঠিকানা থাকতে পারে, কিন্তু কার্ট একটিই। Foreign key সবসময় “অনেক” দিকে বসে। One-to-one-এ যে সারি অন্যটি ছাড়া বাঁচতে পারে না, foreign key তার দিকে রাখুন। কার্ট ব্যবহারকারী ছাড়া অর্থহীন, তাই userId থাকে Cart-এ।

Migration চালালে এই লেখা থেকে যা তৈরি হয়, তা সাধারণ SQL. নিচের লাইনগুলো Prisma-র বানানো ফাইল থেকে সরাসরি নেওয়া:

CREATE UNIQUE INDEX "Cart_userId_key" ON "Cart"("userId");
ALTER TABLE "Cart" ADD CONSTRAINT "Cart_userId_fkey" FOREIGN KEY ("userId")
  REFERENCES "User"("id") ON DELETE CASCADE ON UPDATE CASCADE;

২ · Many-to-many — implicit না explicit join table

একটি অর্ডারে অনেক পণ্য, একটি পণ্য অনেক অর্ডারে। এই many-to-many সম্পর্ক কোনো একটি table-এর কলামে রাখা যায় না। মাঝখানে লাগে একটি join table, ঠিক যেন বিয়ের রেজিস্টার খাতা, যার প্রতিটি লাইন দুজন মানুষকে জোড়ে।

Prisma দুভাবে এটি লিখতে দেয়। Implicit: দুই দিকে শুধু list লিখলেই Prisma নিজে table বানায়। Explicit: আপনি join table-কে সাধারণ model হিসেবে লেখেন। বাজারঘরে দুটোই আছে:

// implicit: পণ্যের tag, লিংকে কোনো বাড়তি তথ্য নেই
model Tag {
  id       Int       @id @default(autoincrement())
  name     String    @unique
  products Product[]
}

// explicit: লিংকটিই একটি আসল জিনিস
model OrderItem {
  id             Int     @id @default(autoincrement())
  orderId        Int
  order          Order   @relation(fields: [orderId], references: [id], onDelete: Cascade)
  productId      Int
  product        Product @relation(fields: [productId], references: [id], onDelete: Restrict)
  productName    String  // snapshot
  unitPricePaisa Int     // snapshot
  quantity       Int

  @@unique([orderId, productId])
  @@index([productId])
}

Implicit-এর table Prisma-র নিজের নিয়মে তৈরি হয়। সত্যিকারের run-এ pg_indexes থেকে পাওয়া ফল (আউটপুট ছাঁটা):

"_ProductToTag" (A, B)     -- A = Product.id, B = Tag.id
_ProductToTag_AB_pkey : UNIQUE btree ("A", "B")
_ProductToTag_B_index : btree ("B")
rows: { A: 1, B: 1 }, { A: 1, B: 2 }, { A: 2, B: 1 }

কলামের নাম A আর B, কারণ এখানে মানুষের কিছু লেখার জায়গা নেই। নিচের ধাপে দেখুন কোন প্রশ্ন দিয়ে সিদ্ধান্ত নেবেন।

Product — Tag     : না, শুধু জোড়া
Order — Product   : হ্যাঁ: quantity, unitPricePaisa
Cart — Product    : হ্যাঁ: quantity

Implicit       : onDelete লেখা যায় না, দুই দিকেই Cascade
OrderItem.order   : Cascade
OrderItem.product : Restrict

ফেরত (refund) : কোন অর্ডারের কোন লাইন?
OrderItem.id  : আছে, নির্দেশ করা যায়
"_ProductToTag" : A, B ছাড়া কিছু নেই

Product — Tag   : implicit চলবে
Order — Product : explicit: OrderItem
Cart — Product  : explicit: CartItem

এবার join table পেরিয়ে পড়ে দেখুন। Live ডেটাবেসটি SQLite (sql.js), আপনার ব্রাউজারেই চলে। আসল বাজারঘর PostgreSQL-এ চলে, তবে এই query-গুলো দুই জায়গাতেই একই। JOIN লিখে ফল বদলে দেখতে পারেন:

-- one-to-many: কার কতগুলো অর্ডার
SELECT u.name, COUNT(o.id) AS orders
FROM users u LEFT JOIN orders o ON o.user_id = u.id
GROUP BY u.id ORDER BY u.id;

-- many-to-many: join table পেরিয়ে অর্ডার থেকে পণ্যে
SELECT o.id AS order_id, p.name, oi.quantity,
       oi.unit_price_paisa * oi.quantity AS line_paisa
FROM orders o
JOIN order_items oi ON oi.order_id = o.id
JOIN products p     ON p.id = oi.product_id
ORDER BY o.id, p.id;

-- উল্টো দিক: পণ্য থেকে অর্ডারে
SELECT p.name, COUNT(*) AS in_orders, SUM(oi.quantity) AS units
FROM products p
JOIN order_items oi ON oi.product_id = p.id
GROUP BY p.id ORDER BY p.id;

৩ · Self relation — category-র গাছ

মুদি → চাল → মিনিকেট। প্রতিটি category-র একটি parent, আর সেই parent-ও একটি category. একটি table নিজেকেই নির্দেশ করলে তাকে self relation বলে। পরিবারের গুষ্টিনামায় প্রত্যেকের পাশে শুধু বাবার নাম লেখা থাকলেও পুরো বংশ বের করা যায়। এই সরল পদ্ধতির নাম adjacency list.

model Category {
  id       Int        @id @default(autoincrement())
  name     String     @unique
  parentId Int?       // মূল category-র parent নেই
  parent   Category?  @relation("CategoryTree", fields: [parentId], references: [id], onDelete: Restrict)
  children Category[] @relation("CategoryTree")
  products Product[]

  @@index([parentId])
}

এখানে সম্পর্কের একটি নাম ("CategoryTree") দিতে হয়, কারণ একই model-এ দুটি দিক আছে, আর Prisma-কে বলতে হয় এরা জোড়া। include দিয়ে পড়লে গভীরতা আগে থেকে ঠিক করে লিখতে হয়, দুই স্তর চাইলে দুবার children. যত গভীর গাছই হোক, এক query-তে পুরোটা পেতে লাগে recursive CTE. এর তত্ত্ব আছে DBMS কোর্সের CTE পর্বে।

-- নিচের দিকে: মুদি-র ভেতরের পুরো গাছ
WITH RECURSIVE tree AS (
  SELECT id, name, 0 AS depth, name AS path
  FROM categories WHERE parent_id IS NULL
  UNION ALL
  SELECT c.id, c.name, t.depth + 1, t.path || ' > ' || c.name
  FROM categories c JOIN tree t ON c.parent_id = t.id
)
SELECT depth, path FROM tree ORDER BY path;

-- ওপরের দিকে: মিনিকেট-এর breadcrumb
WITH RECURSIVE up AS (
  SELECT id, name, parent_id, 0 AS step
  FROM categories WHERE name = 'মিনিকেট'
  UNION ALL
  SELECT c.id, c.name, c.parent_id, u.step + 1
  FROM categories c JOIN up u ON c.id = u.parent_id
)
SELECT step, name FROM up ORDER BY step DESC;

৪ · onDelete — parent মুছলে child-এর কী হবে

একজন ব্যবহারকারী account মুছতে চাইলেন। তাঁর কার্ট, ঠিকানা, অর্ডার, রিভিউ কী হবে? এই প্রশ্নের উত্তর কোড নয়, ব্যবসা ঠিক করে। উত্তরটি foreign key-তে লেখা হয় referential action হিসেবে, আর PostgreSQL নিজে তা মানে। আপনার কোডে ভুল থাকলেও এই নিয়ম ভাঙে না।

না লিখলে Prisma ডিফল্ট বসায়: বাধ্যতামূলক সম্পর্কে Restrict, optional সম্পর্কে SetNull. উপরের Product.categoryId-তে কিছু লেখা হয়নি, তাই migration-এ এসেছে ON DELETE RESTRICT. নিচে সত্যিকারের run-এর সংখ্যা দিয়ে একটি মোছা দেখুন।

1-- করিম: অর্ডার নেই2Address.userId  CASCADE3Cart.userId     CASCADE4CartItem.cartId CASCADE5Review.userId   SET NULL6-- রহিমা: অর্ডার আছে7Order.userId    RESTRICT

সত্যিকারের run-এ Prisma-র error-এর ভেতরের অংশ (আউটপুট ছাঁটা):

code: 'P2003', originalCode: '23001',
update or delete on table "User" violates RESTRICT setting of
foreign key constraint "Order_userId_fkey" on table "Order"

একই run-এ Product, Category আর payment-সহ Order মুছতেও একই P2003 এসেছে। শেষেরটি লক্ষ করুন: Order → OrderItem হলো Cascade, কিন্তু Order → Payment হলো Restrict. Payment-সহ অর্ডার তাই মোছা যায় না। Payment ছাড়া অর্ডার মুছলে লাইনগুলো গেছে (৩ থেকে ২)। ঠিকানা মোছার পর অর্ডারের addressId হয়েছে null, কিন্তু কপি করা shipLine “১২ লেক রোড” ঠিকই রয়ে গেছে। এই কপির কারণ ষষ্ঠ অংশে।

PRAGMA foreign_keys = ON;  -- SQLite-এ প্রতি সংযোগে আলাদা করে চালু করতে হয়

SELECT COUNT(*) AS items_before FROM order_items;

-- CASCADE: অর্ডার 2 গেলে তার লাইনও যাবে
DELETE FROM orders WHERE id = 2;
SELECT COUNT(*) AS items_after FROM order_items;

-- সুমির কোনো অর্ডার নেই: RESTRICT আটকাবে না
DELETE FROM users WHERE id = 3;

-- RESTRICT: পণ্য 1 অর্ডারে আছে, তাই আটকাবে
DELETE FROM products WHERE id = 1;
SELECT 'এই লাইন চলবে না' AS note;

৫ · Foreign key-র index — PostgreSQL নিজে বানায় না

অনেকের ধারণা, foreign key মানেই index. MySQL-এর InnoDB সত্যিই তা বানায়। Prisma-র relation mode পাতাতেও লেখা আছে database সাধারণত foreign key-তে index বানায়। কিন্তু PostgreSQL বানায় না। তাদের docs স্পষ্ট বলে: “the declaration of a foreign key constraint does not automatically create an index on the referencing columns.” কথাটি শুনে না মেনে যাচাই করি। @@index ছাড়া দুটি model থেকে Prisma যা বানাল (সত্যিকারের prisma migrate diff, ছাঁটা):

$ npx prisma migrate diff --from-empty --to-schema fk/schema.prisma --script
CREATE TABLE "Order" (...);
CREATE TABLE "OrderItem" ( "id" SERIAL NOT NULL, "orderId" INTEGER NOT NULL, ... );
ALTER TABLE "OrderItem" ADD CONSTRAINT "OrderItem_orderId_fkey" FOREIGN KEY ("orderId")
  REFERENCES "Order"("id") ON DELETE CASCADE ON UPDATE CASCADE;

-- PostgreSQL-কে জিজ্ঞেস করা হলো:
indexes: [ 'Order_pkey', 'OrderItem_pkey' ]     orderId-তে কিছু নেই

এর দাম কত? ১ লাখ অর্ডার আর ৩ লাখ OrderItem ঢুকিয়ে মাপা হলো। এগুলো এই মেশিনের একটি local run, সাধারণ ফল নয়, তবে অনুপাতটি শিক্ষণীয়:

Plan-টিও সত্যিকারের run থেকে নেওয়া (ছাঁটা):

EXPLAIN (ANALYZE) SELECT * FROM "OrderItem" WHERE "orderId" = 54321
-- index ছাড়া
Gather (actual rows=3.00 loops=1)
  ->  Parallel Seq Scan on "OrderItem" (actual rows=1.50 loops=2)
        Filter: ("orderId" = 54321)
        Rows Removed by Filter: 149998
-- index-সহ
Index Scan using "OrderItem_orderId_idx" on "OrderItem" (actual rows=3.00 loops=1)
  Index Cond: ("orderId" = 54321)

হিসাবটি কেন এত বড়

PostgreSQL-এ ON DELETE চলে ভেতরের trigger দিয়ে। প্রতিটি মোছা অর্ডারের জন্য সে child table-এ মিল খোঁজে। Index না থাকলে প্রতিবার Seq Scan:

• পরীক্ষা করা সারি ≈ ২০০ × ৩,০০,০০০ = ৬ কোটি
• প্রতি অর্ডারে সময় = ১৬৭১.৩ ms ÷ ২০০ ≈ ৮.৪ ms
• অনুপাত = ১৬৭১.৩ ÷ ১.১ ≈ প্রায় ১,৫০০ গুণ
• ২,০০০ অর্ডার মুছলে, সময় সমানুপাতিক ধরে: index ছাড়া ≈ ১৬.৭ সেকেন্ড, index-সহ ≈ ১১ ms

সবচেয়ে বিপজ্জনক দিকটি হলো, parent মোছার কোডে child table-এর নাম কোথাও নেই। তাই ধীরগতি দেখে কারণ খুঁজে পাওয়া কঠিন। যে কলামে include, JOIN বা Cascade চলবে, সেখানে index দিন। সব মিলিয়ে নিয়মটি সহজ: সব foreign key-তে @@index, যদি না কলামটি আগে থেকেই কোনো index-এর প্রথম কলাম হয়।

এই শেষ শর্তটি বাজারঘরে কাজে লেগেছে। OrderItem-এ @@unique([orderId, productId]) আছে, তাই orderId-এর আলাদা index লাগেনি, লেগেছে শুধু productId-এ। Order-এ @@index([userId, createdAt(sort: Desc)]) একই সাথে “এই ব্যবহারকারীর সাম্প্রতিক অর্ডার” তালিকার কাজও করে।

একটি সত্যি কথা বলি। এই পর্বের schema লেখার সময় আমরাও Address.userId-তে index দিতে ভুলে গিয়েছিলাম। নিচের query-টি সেটি ধরে ফেলে, আর পরের migration-এ ঠিক করা হয়। একে আপনার প্রজেক্টের CI-তেও রাখতে পারেন:

SELECT c.conrelid::regclass::text AS tbl, a.attname AS col
FROM pg_constraint c
JOIN pg_attribute a ON a.attrelid = c.conrelid AND a.attnum = c.conkey[1]
WHERE c.contype = 'f'
  AND NOT EXISTS (
    SELECT 1 FROM pg_index i
    WHERE i.indrelid = c.conrelid AND i.indkey[0] = a.attnum);

-- প্রথমবার (সত্যিকারের run)            -- index যোগের পর
"Address"   userId                       []

৬ · অর্ডার লেখা — nested write আর দামের snapshot

আজ রহিমা ১৮৫ টাকায় তেল কিনলেন। আগামী মাসে দাম হলো ২১০ টাকা। তাঁর পুরোনো রসিদ কি বদলে যাবে? রিকশাভাড়ার রসিদ বা মুদি দোকানের মেমো যেমন লেখার পর বদলায় না, অর্ডারও তেমনি একটি ঐতিহাসিক দলিল। তাই অর্ডার লেখার মুহূর্তে দাম, নাম আর ঠিকানা কপি করে রাখা হয়। একে বলে snapshot.

Snapshot-সহ একটি অর্ডার কয়েকটি table-এ লেখা হয়, আর সব একসাথে হতে হবে। অর্ধেক অর্ডার থাকা চলবে না। Prisma-র nested write এই কাজটি এক কলে করে। connect মানে সারিটি আগেই আছে, শুধু জোড়া হবে। আর create মানে নতুন সারি তৈরি হবে। সত্যিকারের run-এর কোড:

const order = await prisma.order.create({
  data: {
    user: { connect: { id: rahima.id } },
    address: { connect: { id: addr.id } },
    shipName: rahima.name,      // snapshot
    shipLine: addr.line,        // snapshot
    shipCity: addr.city,        // snapshot
    totalPaisa: 18500,
    items: {
      create: [{
        product: { connect: { id: soybean.id } },
        productName: soybean.name,          // snapshot
        unitPricePaisa: soybean.pricePaisa, // snapshot
        quantity: 1,
      }],
    },
  },
  include: { items: true },
});

Client তৈরিতে log: [{ emit: "event", level: "query" }] দিলে Prisma তার পাঠানো SQL দেখায়। নিচের ধাপগুলো সেই log থেকে নেওয়া, ক্রমও একই:

SELECT "Address"."id" FROM "Address" WHERE ...
SELECT "User"."id" FROM "User" WHERE ...

INSERT INTO "Order" ("userId","addressId","status",
  "shipName","shipLine","shipCity","totalPaisa",...)
VALUES ($1,$2,...)
-- ফল: Order id = 2, totalPaisa = 18500

SELECT "Product"."id" FROM "Product" WHERE ...
-- পণ্য 2 পাওয়া গেল

INSERT INTO "OrderItem" ("orderId","productId",
  "productName","unitPricePaisa","quantity")
VALUES ($1,$2,$3,$4,$5)
-- orderId=2, unitPricePaisa=18500, quantity=1

SELECT ... FROM "Order" ...
SELECT ... FROM "OrderItem" ...
COMMIT

অস্তিত্বহীন পণ্য 9999 দিয়ে একই কল চালিয়ে দেখা হলো। অর্ডারের INSERT আগে হলেও শেষে কিছুই রইল না (সত্যিকারের run, ছাঁটা):

code: 'P2025', operation: 'a nested connect', model: 'Product'
orders before/after: 2 2

-- সয়াবিন তেলের দাম বাড়ল
UPDATE products SET price_paisa = 21000 WHERE id = 2;

-- অর্ডার 1: যা দিয়েছেন বনাম আজকের দাম
SELECT p.name, oi.quantity,
       oi.unit_price_paisa AS paid,
       p.price_paisa AS today
FROM order_items oi JOIN products p ON p.id = oi.product_id
WHERE oi.order_id = 1;

-- snapshot না থাকলে পুরোনো মোট ভুল আসত
SELECT o.id, o.total_paisa,
       SUM(oi.unit_price_paisa * oi.quantity) AS by_snapshot,
       SUM(p.price_paisa * oi.quantity) AS by_today_price
FROM orders o
JOIN order_items oi ON oi.order_id = o.id
JOIN products p ON p.id = oi.product_id
GROUP BY o.id;

৭ · Soft delete — সহজ চেহারার ফাঁদ

পণ্যে অর্ডার থাকলে Restrict তাকে মুছতে দেবে না, অথচ দোকান থেকে সরাতে হবে। সাধারণ সমাধান soft delete: সারি না মুছে deletedAt কলামে সময় বসানো। দোকানের তাক থেকে পণ্য সরিয়ে গুদামে রাখার মতো। এতে ইতিহাস বাঁচে, ভুল করে মুছলে ফেরানো যায়। কিন্তু এই পদ্ধতিতে database আর আপনাকে সাহায্য করে না। সব পাহারা চলে আসে আপনার কোডে। সত্যিকারের run-এ চারটি ফাঁদ:

চার নম্বর ফাঁদের কারণ সরল: soft delete আসলে একটি UPDATE, আর ON DELETE শুধু DELETE-এ চলে। তিন নম্বরের প্রতিকার Prisma 7.4 থেকে preview হিসেবে আছে। Generator-এ previewFeatures = ["partialIndexes"] লিখে:

model User {
  id        Int       @id @default(autoincrement())
  email     String
  deletedAt DateTime?

  @@unique([email], where: raw("\"deletedAt\" IS NULL"))
}

CREATE UNIQUE INDEX "User_email_key" ON "User"("email") WHERE ("deletedAt" IS NULL);

-- সত্যিকারের run
{ id: 3, email: 'sumi@example.com', soft_deleted: true }
{ id: 5, email: 'sumi@example.com', soft_deleted: false }   নতুন signup সফল
তৃতীয় চেষ্টা, জীবিত account-এর সাথে একই email: P2002

এখানেই সবচেয়ে সূক্ষ্ম ফাঁদটি ধরা পড়েছে, যা আমরা আগে থেকে ভাবিনি। এই schema-র পরও Prisma 7.10.1-এর type-এ findUnique({ where: { email } }) বৈধ থাকে, অথচ email আর সত্যিই unique নয়। নতুন database-এ পুরোনো আর নতুন সুমি বানিয়ে চালিয়ে দেখা ফল:

findUnique email only:             {"id":2,"name":"পুরোনো সুমি","deletedAt":"2026-11-01..."}
findUnique email + deletedAt null: {"id":3,"name":"নতুন সুমি","deletedAt":null}

অর্থাৎ login-এর কোডে শর্তটি ভুলে গেলে মোছা account ফেরত আসতে পারে। তাই partial unique ব্যবহার করলে সবসময় deletedAt: null সাথে লিখুন, আর এর জন্য একটি test রাখুন। Preview feature বদলাতে পারে, তাই নিজের version-এ যাচাই করুন।

৮ · Polymorphic সম্পর্ক — একটি ছবি, দুই মালিক

পণ্যের ছবি আছে, রিভিউয়েরও ছবি আছে। একটি Image table কি দুটোরই হতে পারে? যে সম্পর্কে এক সারি একাধিক ধরনের table-এর সাথে জুড়তে পারে, তাকে polymorphic relation বলে। Prisma-র schema-য় এর জন্য সরাসরি কোনো syntax আমরা পাইনি, তাই বিকল্পগুলো জানা দরকার:

শেষ পদ্ধতিটি সবচেয়ে প্রচলিত, আবার সবচেয়ে ঝুঁকিপূর্ণ। সত্যিকারের run-এ PostgreSQL ('Product', 9999) সারিটি চুপচাপ নিয়েছে, যদিও ওই পণ্য নেই (rows inserted: 1). বাজারঘরে তাই exclusive arc. Prisma-র schema-য় CHECK লেখার উপায় নেই, তাই হাতে লেখা migration লাগে। prisma migrate dev --create-only শুধু ফাঁকা বা তৈরি ফাইল বানায়, ফাইলটি আপনি সম্পাদনা করে তারপর চালান:

-- Prisma schema cannot say this, so it is written by hand.
-- A row in Image belongs to exactly one owner.
ALTER TABLE "Image" ADD CONSTRAINT "Image_one_owner"
  CHECK (num_nonnulls("productId", "reviewId") = 1);

ALTER TABLE "OrderItem" ADD CONSTRAINT "OrderItem_quantity_positive"
  CHECK ("quantity" > 0);

-- সত্যিকারের run, ছাঁটা
image with no owner      : P2039, 23514 "Image_one_owner"
image with two owners    : P2039, 23514 "Image_one_owner"
image with one owner     : OK {"id":3,"url":"a.webp","productId":2,"reviewId":null}
owner 9999 does not exist: P2003 "Image_productId_fkey"
quantity 0               : P2039, 23514 "OrderItem_quantity_positive"

P2039 লেখার সময়ে Prisma 7-এর error reference-এর তালিকায় নেই। Prisma-র ২০২৬ সালের এপ্রিলের changelog অনুযায়ী এটি একটি সাধারণ “Database error”, যার নিজস্ব Prisma code নেই এমন driver error এতে মোড়া থাকে। তাই কারণ বুঝতে ভেতরের PostgreSQL code (23514, CHECK ভাঙা) আর constraint-এর নামই দেখুন। পর্ব ৪৩-এও একই code আসবে।

CHECK constraint Prisma দেখতে পায় না, তবু এতে সমস্যা হয়নি: migrate status বলেছে “Database schema is up to date!”, আর migrate diff কোনো পার্থক্য দেখায়নি। শুধু মনে রাখুন, নিয়মটি থাকে migration ফাইলে, schema.prisma-য় নয়। সেখানে একটি মন্তব্য লিখে রাখা ভালো।

৯ · পুরো বাজারঘর — schema, migration আর seed

এবার সব জোড়া দিই। নিচের ছবিটি বাজারঘরের ER diagram. ER নকশার নিয়ম জানতে দেখুন DBMS কোর্সের ER পর্ব আর নকশার case study.

নিচে সত্যিকারের চূড়ান্ত schema.prisma. প্রতিটি মন্তব্য একটি সিদ্ধান্ত। লম্বা, তাই ধীরে পড়ুন:

generator client {
  provider        = "prisma-client"
  output          = "../generated/prisma"
  previewFeatures = ["partialIndexes"]
}

datasource db {
  provider = "postgresql"
}

enum OrderStatus {
  PENDING
  PAID
  SHIPPED
  DELIVERED
  CANCELLED
}

enum PaymentStatus {
  INITIATED
  SUCCESS
  FAILED
}

model User {
  id        Int       @id @default(autoincrement())
  email     String
  name      String
  createdAt DateTime  @default(now())
  deletedAt DateTime?
  addresses Address[]
  cart      Cart?
  orders    Order[]
  reviews   Review[]

  @@unique([email], where: raw("\"deletedAt\" IS NULL"))
}

model Address {
  id     Int     @id @default(autoincrement())
  userId Int
  user   User    @relation(fields: [userId], references: [id], onDelete: Cascade)
  label  String
  line   String
  city   String
  orders Order[]

  @@index([userId])
}

model Category {
  id       Int        @id @default(autoincrement())
  name     String     @unique
  parentId Int?
  parent   Category?  @relation("CategoryTree", fields: [parentId], references: [id], onDelete: Restrict)
  children Category[] @relation("CategoryTree")
  products Product[]

  @@index([parentId])
}

model Tag {
  id       Int       @id @default(autoincrement())
  name     String    @unique
  products Product[] // implicit many-to-many
}

model Product {
  id          Int         @id @default(autoincrement())
  name        String
  pricePaisa  Int
  categoryId  Int
  category    Category    @relation(fields: [categoryId], references: [id])
  deletedAt   DateTime?
  avgRating   Float       @default(0) // denormalised
  reviewCount Int         @default(0) // denormalised
  tags        Tag[]
  inventory   Inventory?
  cartItems   CartItem[]
  orderItems  OrderItem[]
  reviews     Review[]
  images      Image[]

  @@index([categoryId])
}

model Inventory {
  productId Int     @id
  product   Product @relation(fields: [productId], references: [id], onDelete: Cascade)
  stock     Int     @default(0)
}

model Cart {
  id        Int        @id @default(autoincrement())
  userId    Int        @unique
  user      User       @relation(fields: [userId], references: [id], onDelete: Cascade)
  items     CartItem[]
  updatedAt DateTime   @updatedAt
}

model CartItem {
  cartId    Int
  productId Int
  quantity  Int
  cart      Cart    @relation(fields: [cartId], references: [id], onDelete: Cascade)
  product   Product @relation(fields: [productId], references: [id], onDelete: Cascade)

  @@id([cartId, productId])
  @@index([productId])
}

model Order {
  id         Int         @id @default(autoincrement())
  userId     Int
  user       User        @relation(fields: [userId], references: [id], onDelete: Restrict)
  addressId  Int?
  address    Address?    @relation(fields: [addressId], references: [id], onDelete: SetNull)
  status     OrderStatus @default(PENDING)
  shipName   String // snapshot
  shipLine   String // snapshot
  shipCity   String // snapshot
  totalPaisa Int // denormalised, sum of the lines
  createdAt  DateTime    @default(now())
  items      OrderItem[]
  payments   Payment[]

  @@index([userId, createdAt(sort: Desc)])
  @@index([addressId])
}

model OrderItem {
  id             Int     @id @default(autoincrement())
  orderId        Int
  order          Order   @relation(fields: [orderId], references: [id], onDelete: Cascade)
  productId      Int
  product        Product @relation(fields: [productId], references: [id], onDelete: Restrict)
  productName    String // snapshot
  unitPricePaisa Int // snapshot
  quantity       Int

  @@unique([orderId, productId])
  @@index([productId])
}

model Payment {
  id          Int           @id @default(autoincrement())
  orderId     Int
  order       Order         @relation(fields: [orderId], references: [id], onDelete: Restrict)
  method      String
  amountPaisa Int
  status      PaymentStatus @default(INITIATED)
  createdAt   DateTime      @default(now())

  @@index([orderId])
}

model Review {
  id        Int      @id @default(autoincrement())
  productId Int
  product   Product  @relation(fields: [productId], references: [id], onDelete: Cascade)
  userId    Int?
  user      User?    @relation(fields: [userId], references: [id], onDelete: SetNull)
  rating    Int
  body      String
  createdAt DateTime @default(now())
  images    Image[]

  @@unique([productId, userId])
  @@index([userId])
}

model Image {
  id        Int      @id @default(autoincrement())
  url       String
  productId Int?
  product   Product? @relation(fields: [productId], references: [id], onDelete: Cascade)
  reviewId  Int?
  review    Review?  @relation(fields: [reviewId], references: [id], onDelete: Cascade)

  @@index([productId])
  @@index([reviewId])
}

লক্ষ করুন, datasource-এ url নেই। Prisma 7-এ সেটি থাকে prisma.config.ts-এ, আর সংযোগ হয় driver adapter দিয়ে (পর্ব ৩৯)। এবার migration আর seed. সত্যিকারের run; ডেটাবেসের নাম আর port বদলে সাধারণ করা হয়েছে, আউটপুট ছাঁটা:

~/bazarghar$ npx prisma migrate dev --name init
Loaded Prisma config from prisma.config.ts.
Prisma schema loaded from prisma\schema.prisma.
Datasource "db": PostgreSQL database "bazarghar", schema "public" at "127.0.0.1:5432"

Applying migration `20261101174952_init`

The following migration(s) have been created and applied from new schema changes:

prisma\migrations/
  └─ 20261101174952_init/
    └─ migration.sql

Your database is now in sync with your schema.

~/bazarghar$ npx prisma generate
✔ Generated Prisma Client (7.10.1) to .\generated\prisma in 142ms

~/bazarghar$ npx prisma db seed
Running seed command `tsx prisma/seed.ts` ...
seed: {
  users: 1,      addresses: 1,  categories: 4,
  tags: 2,       products: 2,   inventory: 2,
  carts: 1,      cartItems: 1,  orders: 1,
  orderItems: 2, payments: 2,   reviews: 1
}
The seed command has been executed.

এই run-এ দুটি জিনিস চোখে পড়ল। migrate dev নিজে থেকে client generate করেনি, seed-ও চালায়নি। দুটোই আলাদা কমান্ডে চালাতে হয়েছে। বাকি তিনটি migration ছিল user_soft_delete, index ও partial unique, আর হাতে লেখা CHECK. শেষে একটি একদম নতুন, ফাঁকা database-এ prisma migrate deploy চালিয়ে ৪টি migration ক্রমে বসানো হয়েছে, seed-ও একই সংখ্যা দিয়েছে। Migration-এর নিরাপদ পথ নিয়ে বিস্তারিত আছে পর্ব ৪০-এ।

পুরো শিকলটি একসাথে পড়লে এই ফল আসে (সত্যিকারের run, তেলের দাম বদলের পরও অর্ডার অপরিবর্তিত, ছাঁটা):

{ "id": 1, "status": "PAID", "shipCity": "রাজশাহী", "totalPaisa": 79000,
  "user": { "name": "রহিমা খাতুন" },
  "items": [
    { "productName": "সয়াবিন তেল ১ লিটার", "unitPricePaisa": 18500, "quantity": 2 },
    { "productName": "মিনিকেট চাল ৫ কেজি", "unitPricePaisa": 42000, "quantity": 1 } ],
  "payments": [
    { "method": "card", "status": "FAILED" },
    { "method": "mobile-wallet", "status": "SUCCESS" } ] }

Denormalization — জেনেবুঝে একই তথ্য দুবার

Normalization বলে, একই তথ্য এক জায়গায় রাখুন (DBMS কোর্স)। অথচ schema-য় totalPaisa আর avgRating দুটোই হিসাব করে বের করা যায়। এটিই denormalization. চায়ের দোকানের খাতায় প্রতি পাতার নিচে মোট লিখে রাখার মতো, যাতে প্রতিবার যোগ করতে না হয়। কিন্তু একটি বিষয় স্পষ্ট করা দরকার: snapshot আর denormalization এক নয়।

Denormalization-এর নিয়ম তিনটি। আগে মেপে দেখুন সত্যিই ধীর কি না। একটি উৎস ঠিক করুন, এখানে Review, আর avgRating শুধু তার ছায়া। আর একই transaction-এ দুটো বদলান, অথবা একটি নিয়মিত কাজ রাখুন যা আবার হিসাব করে মিলিয়ে দেবে। ২ লাখ পণ্যের তালিকায় প্রতি কার্ডে রিভিউ গড় হিসাব করার বদলে একটি কলাম পড়া সস্তা, কিন্তু ৫০০ পণ্যের দোকানে এই জটিলতা হয়তো লাগবেই না। গভীর আলোচনা আছে DBMS কোর্সের denormalization পর্বে।

১০ · AI-এর যুগে — ডেটা মডেল যাচাই

AI এক মিনিটে সুন্দর schema লিখে দেয়। Schema কোডের চেয়েও বিপজ্জনক জায়গা, কারণ ভুল কোড বদলানো যায়, কিন্তু ভুল ডেটা নিয়ে এক বছর চললে migration হয়ে যায় কঠিন প্রকল্প। AI-এর লেখা schema-য় সাধারণত যা পাবেন:

AI agent দিয়ে কাজ করলে আরেকটি বিষয় জেনে রাখুন। Prisma 7.10.1-এ migrate reset agent থেকে চালানোর চেষ্টা করলে সে নিজেই থেমে যায়, আর ব্যবহারকারীর স্পষ্ট সম্মতি চায়। এই পর্ব লেখার সময় আমাদের run-এ ঠিক এটিই ঘটেছে, আর আমরা সেই পাহারা এড়াইনি, নতুন ফাঁকা database-এ কাজ করেছি। সতর্কবার্তাটি পাশ কাটানোর পরামর্শ AI দিলে মানবেন না, আর production-এর connection string কখনো AI-কে দেবেন না।

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

• npx prisma --version দেখে সেই version-এর docs মিলিয়েছি
• প্রতিটি onDelete-এর ব্যবসায়িক কারণ নিজের ভাষায় বলতে পারি
• Migration-এর SQL ফাইল পড়েছি, শুধু “success” দেখে থামিনি
• Audit query চালিয়েছি: index ছাড়া কোনো foreign key নেই
• অর্ডার রাখার পর দাম আর ঠিকানা বদলে পুরোনো অর্ডার মিলিয়েছি
• Parent মুছে দেখেছি কোন child গেল, কোনটি রইল