View আর materialized view

১ · View কী — নাম দেওয়া একটি প্রশ্ন

একটি মুদি দোকানের মূল খাতায় সব লেনদেন লেখা থাকে: কে কী নিলেন, কত দাম, কবে, নগদ না বাকি। মাসের শেষে মালিক চান “বাকির তালিকা”। হিসাবরক্ষক প্রতিবার মূল খাতা দেখে তালিকাটি নতুন করে বানান — আলাদা খাতায় কপি করে রাখেন না। তালিকাটির একটি নাম আছে, একটি নিয়ম আছে (“যাঁদের বাকি শূন্যের বেশি”), কিন্তু নিজস্ব কোনো ডেটা নেই। আজ কেউ বাকি শোধ করলে আজকের তালিকায় তাঁর নাম আর আসবে না।

SQL-এ ঠিক এই জিনিসটি হলো view. View হলো একটি SELECT কোয়েরি, যাকে একটি নাম দিয়ে ডেটাবেসে রেখে দেওয়া হয়েছে। তারপর সেই নাম টেবিলের মতোই FROM-এ লেখা যায়। এজন্য view-কে বলে virtual table (ভার্চুয়াল টেবিল): দেখতে টেবিল, কিন্তু ভেতরে শুধু একটি প্রশ্ন। যে আসল টেবিলগুলো থেকে view ডেটা নেয়, তাদের বলে base table (মূল টেবিল)।

পর্ব ৩-এ three-schema architecture-এর external schema দেখেছিলেন: প্রতিটি ব্যবহারকারী ডেটাবেসের নিজের অংশটুকু নিজের মতো করে দেখেন। SQL-এ external schema লেখার প্রধান হাতিয়ারই view. সেখানে গুদামের জন্য দাম-লুকানো একটি view বানিয়েছিলেন। এই পর্বে view-কে পুরোপুরি চিনবেন।

CREATE VIEW view_name AS
SELECT ...;            -- যেকোনো বৈধ SELECT: JOIN, GROUP BY, subquery সব চলে

SELECT * FROM view_name WHERE ...;   -- টেবিলের মতো ব্যবহার
DROP VIEW view_name;                 -- শুধু সংজ্ঞা মোছে, base table-এর ডেটা অক্ষত

এই পর্বের লাইভ SQL চলে আগের পর্বগুলোর দুটি নমুনা ডেটাবেসে। db-shop একটি দোকান: customers (customer_id, name, city, phone, joined_on — ৮ জন; Tanvir-এর phone নেই, Imran-এর city নেই), categories, products (product_id, name, category_id, price, stock — ১০টি পণ্য), orders (order_id, customer_id, order_date, status — ১০টি অর্ডার, status হলো pending, shipped, delivered বা cancelled) আর order_items (order_id, product_id, quantity, unit_price). db-uni একটি বিশ্ববিদ্যালয়: students (student_id, name, dept_id, batch, cgpa), courses (course_id, title, dept_id, credits, instructor_id), enrollments (student_id, course_id, term, grade) আর departments, instructors. প্রতিবার চালালে ডেটাবেস নতুন করে তৈরি হয়, তাই প্রতিটি এডিটরে দরকারি view আবার বানানো হয়েছে।

প্রথম view-টি এই পর্ব জুড়ে কাজে লাগবে। দোকানের প্রায় প্রতিটি রিপোর্টে একই প্রশ্ন লাগে: কোন অর্ডার, কোন গ্রাহকের, কবে, কী অবস্থায়, আর মোট কত টাকা? উত্তরের জন্য তিনটি টেবিল জুড়তে হয় আর GROUP BY করতে হয় (পর্ব ১৮–১৯). একবার order_summary নামে লিখে রাখলে আর কাউকে সেটি আবার লিখতে হবে না:

-- প্রতিটি অর্ডারের সারাংশ: একবার লিখে রাখা
CREATE VIEW order_summary AS
SELECT o.order_id, c.name AS customer, o.order_date, o.status,
       SUM(i.quantity * i.unit_price) AS total
FROM orders o
JOIN customers c   ON c.customer_id = o.customer_id
JOIN order_items i ON i.order_id = o.order_id
GROUP BY o.order_id, c.name, o.order_date, o.status;

SELECT * FROM order_summary;

-- এখন টেবিলের মতোই ছাঁকা আর সাজানো
SELECT customer, total FROM order_summary
WHERE status = 'delivered' AND total > 3000
ORDER BY total DESC;

২ · View কেন — চারটি বাস্তব কারণ

নিরাপত্তা: কলাম আর সারি লুকানো

দোকানের হিসাব শাখা গ্রাহকের নাম আর শহর দেখবে, কিন্তু ফোন নম্বর নয় — ফোন নম্বর ব্যক্তিগত তথ্য, আর যার কাজে লাগে না তার কাছে না থাকাই নিরাপদ। ঢাকা শাখার কর্মী শুধু ঢাকার গ্রাহক দেখবেন। প্রথম view কলাম লুকায় (SELECT তালিকা দিয়ে), দ্বিতীয়টি সারিও লুকায় (WHERE দিয়ে):

-- হিসাব শাখার জন্য: ফোন নম্বর ছাড়া
CREATE VIEW public_customers AS
SELECT customer_id, name, city, joined_on FROM customers;

-- ঢাকা শাখার জন্য: শুধু ঢাকার সারি
CREATE VIEW dhaka_customers AS
SELECT customer_id, name, city FROM customers WHERE city = 'Dhaka';

SELECT * FROM public_customers WHERE customer_id <= 3;
SELECT * FROM dhaka_customers;

-- view-তে phone নেই
SELECT name, phone FROM public_customers;

সরলতা: বিশ্ববিদ্যালয়ের transcript

বিশ্ববিদ্যালয়ের রেজিস্টার অফিসে প্রতিদিন একই প্রশ্ন: এই শিক্ষার্থী কোন কোর্সে কী গ্রেড পেলেন, মোট কত credit নিলেন? তিনটি টেবিলের JOIN একবার transcript নামে লিখে রাখলে প্রতিটি প্রশ্ন একটি সরল SELECT হয়ে যায়:

CREATE VIEW transcript AS
SELECT s.student_id, s.name, e.course_id, c.title, c.credits, e.term, e.grade
FROM students s
JOIN enrollments e ON e.student_id = s.student_id
JOIN courses c     ON c.course_id = e.course_id;

SELECT name, course_id, grade FROM transcript WHERE student_id = 2101;

SELECT name, SUM(credits) AS credits_taken FROM transcript
GROUP BY student_id, name ORDER BY credits_taken DESC;

৩ · ভেতরে কী হয় — view expansion

View-এর ওপর কোয়েরি চালালে DBMS কি আগে view-এর পুরো ফল বানিয়ে তারপর ছাঁকে? সাধারণত না। Optimizer কোয়েরির লেখায় view-এর নামের জায়গায় তার সংজ্ঞাটি বসিয়ে দেয়, যেন আপনি FROM-এ একটি derived table (পর্ব ২১) লিখেছেন। তারপর সম্ভব হলে সেই subquery-কে বাইরের কোয়েরির সাথে মিশিয়ে ফেলে, যাতে শেষে শুধু base table-এর ওপর একটি সাধারণ কোয়েরি থাকে। এই প্রক্রিয়ার নাম view expansion (view merging বা inlining নামেও পরিচিত)। নিচে ঢাকা শাখার একটি প্রশ্ন ধাপে ধাপে দেখুন: “ঢাকার কোন গ্রাহকের অর্ডার এখন পথে (shipped)?”

নিজে যাচাই করুন। এই এডিটরে dhaka_customers আর অংশ ১-এর order_summary আগে থেকেই বানানো আছে (নমুনা ডেটার বাক্সের শেষে দেখতে পাবেন)। EXPLAIN QUERY PLAN (পর্ব ১৭-এ প্রথম দেখেছেন) দেখায় SQLite কোয়েরিটি কীভাবে চালাবে:

-- view-এর ওপর কোয়েরি
EXPLAIN QUERY PLAN
SELECT d.name, o.order_id FROM dhaka_customers d
JOIN orders o ON o.customer_id = d.customer_id
WHERE o.status = 'shipped';

-- একই প্রশ্ন, হাতে view খুলে লেখা
EXPLAIN QUERY PLAN
SELECT c.name, o.order_id FROM customers c
JOIN orders o ON o.customer_id = c.customer_id
WHERE c.city = 'Dhaka' AND o.status = 'shipped';

-- GROUP BY-ওয়ালা view: মেশানো যায় না, কিন্তু শর্ত ভেতরে ঠেলা যায়
EXPLAIN QUERY PLAN
SELECT * FROM order_summary WHERE order_id = 1005;

৪ · View-এর ওপর view, বদলানো আর মোছা

View যেহেতু টেবিলের মতো আচরণ করে, একটি view-এর ওপর আরেকটি view-ও বানানো যায়। দোকানের মালিক প্রতি মাসের আয় দেখতে চান। ব্যবসার নিয়ম: বাতিল অর্ডার আয় নয়। নিয়মটি রিপোর্ট-লেখকের মাথায় না রেখে view-এর ভেতরে রাখুন, তাহলে সবাই একই সংখ্যা পাবেন। এই এডিটরে order_summary আগে থেকে বানানো:

-- view-এর ওপর view: মাসভিত্তিক আয় (বাতিল অর্ডার আয় নয়)
CREATE VIEW monthly_revenue AS
SELECT substr(order_date, 1, 7) AS month,
       COUNT(*) AS n_orders, SUM(total) AS revenue
FROM order_summary
WHERE status <> 'cancelled'
GROUP BY substr(order_date, 1, 7);

SELECT * FROM monthly_revenue;

-- একই view থেকে আরেকটি রিপোর্ট: সেরা তিন গ্রাহক
SELECT customer, SUM(total) AS spent FROM order_summary
WHERE status <> 'cancelled'
GROUP BY customer ORDER BY spent DESC LIMIT 3;

View বদলানো: CREATE OR REPLACE

নিয়ম বদলাতে পারে: হিসাব শাখা বলল, আয় গুনবে শুধু delivered অর্ডার, কারণ pending অর্ডার বাতিলও হতে পারে। PostgreSQL, MySQL আর Oracle-এ CREATE OR REPLACE VIEW এক স্টেটমেন্টে সংজ্ঞা বদলায় (SQL Server-এ CREATE OR ALTER VIEW). SQLite-এ এটি নেই; সেখানে DROP VIEW করে আবার CREATE VIEW করতে হয়। আর যে view অন্য view-এর ভিত্তি, সেটি মুছলে কী হয়? এই এডিটরে order_summary আর monthly_revenue দুটিই আগে থেকে বানানো:

SELECT type, name FROM sqlite_schema WHERE type = 'view';

-- নতুন নিয়ম: শুধু delivered অর্ডার আয়
DROP VIEW monthly_revenue;
CREATE VIEW monthly_revenue AS
SELECT substr(order_date, 1, 7) AS month, COUNT(*) AS n_orders,
       SUM(total) AS revenue
FROM order_summary WHERE status = 'delivered'
GROUP BY substr(order_date, 1, 7);
SELECT * FROM monthly_revenue;

-- ভিত্তির view-টি মুছলে?
DROP VIEW order_summary;
SELECT * FROM monthly_revenue;

PostgreSQL এখানে কড়া। এটি view বানানোর সময়েই প্রতিটি টেবিল আর কলাম যাচাই করে, আর নির্ভরতার হিসাব রাখে (pg_depend catalog-এ)। তাই যে জিনিসের ওপর কোনো view নির্ভর করে, সেটি সরাসরি মোছা বা বদলানো যায় না:

DROP VIEW order_summary;
-- ERROR:  cannot drop view order_summary because other objects depend on it
-- DETAIL:  view monthly_revenue depends on view order_summary
-- HINT:  Use DROP ... CASCADE to drop the dependent objects too.

DROP VIEW order_summary CASCADE;      -- monthly_revenue-ও মুছে যাবে!

ALTER TABLE orders ALTER COLUMN status TYPE varchar(20);
-- ERROR:  cannot alter type of a column used by a view or rule

-- CREATE OR REPLACE: পুরোনো কলামগুলো একই নাম, ক্রম আর টাইপে রাখতে হবে;
-- শুধু শেষে নতুন কলাম যোগ করা যায়
CREATE OR REPLACE VIEW monthly_revenue AS
SELECT substr(order_date, 1, 7) AS month, COUNT(*) AS n_orders,
       SUM(total) AS revenue
FROM order_summary WHERE status = 'delivered'
GROUP BY 1;

পর্ব ২৩-এ দেখেছিলেন, SQLite-ও view-এ ব্যবহৃত কলাম DROP COLUMN করতে দেয় না — কারণ ALTER চলার সময় SQLite পুরো schema নতুন করে parse করে দেখে। কিন্তু view মোছায় সে এই পরীক্ষা করে না। আরেকটি পার্থক্য: SQLite CREATE VIEW-এর সময় কলামের নামও যাচাই করে না — ভুল কলামের view তৈরি হয়ে যায়, ত্রুটি আসে প্রথম ব্যবহারে। আর PostgreSQL view-এর SELECT * তৈরির মুহূর্তেই কলামের তালিকায় বদলে রাখে, তাই পরে base table-এ নতুন কলাম যোগ হলে view-তে আসে না; SQLite প্রতিবার লেখাটি নতুন করে পড়ে, তাই আসে। দুই আচরণ জানা থাকলে migration-এর সময় চমক কম হয়।

৫ · View-তে লেখা — updatable view আর WITH CHECK OPTION

View পড়া সহজ। কিন্তু view-তে INSERT, UPDATE বা DELETE করলে কী হবে? view-এর নিজের কোনো সারি নেই, তাই পরিবর্তনটি কোনো base table-এ পৌঁছাতে হবে। প্রশ্ন হলো, DBMS কি নিশ্চিতভাবে বুঝতে পারে কোন টেবিলের কোন সারি বদলাতে হবে? যেমন monthly_revenue-এ “সেপ্টেম্বরের আয় 30000 করো” — কোন অর্ডারের কোন লাইনের দাম কত বাড়বে? এর কোনো একক উত্তর নেই। তাই শুধু সরল view-তেই লেখা যায়। এমন view-কে বলে updatable view.

PostgreSQL ৯.৩ (২০১৩) থেকে এমন সরল view নিজে থেকেই updatable; MySQL অনেক আগে থেকে। public_customers আর dhaka_customers দুটিই এই নিয়মে পড়ে। PostgreSQL-এ UPDATE dhaka_customers SET city = 'Khulna' WHERE customer_id = 3 চালালে DBMS এটিকে লিখে নেয় UPDATE customers SET city = 'Khulna' WHERE customer_id = 3 AND city = 'Dhaka' — view-এর WHERE নিজে থেকে যোগ হয়, তাই view-এর বাইরের সারি (যেমন Khulna-র Tanvir) এই view দিয়ে বদলানো যায় না। কিন্তু একটি অদ্ভুত ব্যাপার ঘটে: সারিটি বদলানোর পর সেটি নিজেই view থেকে উধাও হয়ে যায়! এটি আটকাতে আছে WITH CHECK OPTION. ধাপে ধাপে দেখুন:

CREATE VIEW dhaka_customers AS
SELECT customer_id, name, city FROM customers
WHERE city = 'Dhaka'
WITH CHECK OPTION;        -- standard-এ ডিফল্ট CASCADED

UPDATE dhaka_customers SET city = 'Khulna' WHERE customer_id = 3;
-- PostgreSQL: ERROR:  new row violates check option for view "dhaka_customers"
-- MySQL:      ERROR 1369 (HY000): CHECK OPTION failed 'shop.dhaka_customers'

-- view-এর ওপর view: LOCAL = শুধু নিজের শর্ত, CASCADED = নিচের সব view-এর শর্তও
CREATE VIEW dhaka_new AS
SELECT * FROM dhaka_customers WHERE customer_id > 5
WITH LOCAL CHECK OPTION;

SQLite-এ এসব কিছুই নেই: SQLite-এর প্রতিটি view শুধু পড়ার জন্য, সে যত সরলই হোক, আর WITH CHECK OPTION লিখলে syntax error আসে। দেখুন:

-- public_customers আগে থেকে বানানো (শুধু এক টেবিল, কোনো GROUP BY নেই)
UPDATE public_customers SET city = 'Gazipur' WHERE customer_id = 7;

৬ · INSTEAD OF trigger — view-তে লেখার নিজের নিয়ম

Trigger হলো ডেটাবেসে রাখা কিছু SQL, যা কোনো ঘটনায় (INSERT, UPDATE, DELETE) DBMS নিজে চালায় — পর্ব ২৯-এ বিস্তারিত দেখবেন। INSTEAD OF trigger একটি বিশেষ ধরন, যা SQLite আর PostgreSQL-এ শুধু view-এ বসে (SQL Server-এ টেবিলেও বসানো যায়)। view-এ কেউ INSERT করলে DBMS সেই INSERT চালায় না; তার বদলে (instead of) trigger-এর ভেতরের SQL চালায়। ভেতরে NEW.column মানে যে সারিটি লেখার চেষ্টা হচ্ছে, তার মান (UPDATE আর DELETE-এ পুরোনো মান OLD.column). এতে view-তে লেখার মানে আপনি নিজে ঠিক করে দেন — এমনকি জটিল view-তেও।

CREATE VIEW public_customers AS
SELECT customer_id, name, city, joined_on FROM customers;

-- view-এ INSERT এলে: customers-এ লেখো, phone ফাঁকা রাখো
CREATE TRIGGER public_customers_ins
INSTEAD OF INSERT ON public_customers
BEGIN
  INSERT INTO customers (customer_id, name, city, phone, joined_on)
  VALUES (NEW.customer_id, NEW.name, NEW.city, NULL, NEW.joined_on);
END;

INSERT INTO public_customers VALUES (9, 'Sumaiya Islam', 'Barishal', '2025-10-20');

SELECT * FROM customers WHERE customer_id >= 8;

একই কৌশলে INSTEAD OF UPDATE OF city ON public_customers লিখে শুধু city বদলানোর অনুমতি দেওয়া যায় (অনুশীলন ৪-এ লিখবেন), আর INSTEAD OF DELETE দিয়ে “মুছে ফেলা” মানে আসলে soft delete — একটি deleted_at কলামে সময় লেখা — বানানো যায়। PostgreSQL, SQL Server আর Oracle-এও INSTEAD OF trigger আছে; জটিল (JOIN বা GROUP BY-ওয়ালা) view-কে লেখার উপযোগী করতে সেখানেও এটিই পথ। MySQL-এ INSTEAD OF trigger নেই।

৭ · Materialized view — ফল জমিয়ে রাখা

সাধারণ view প্রতিবার নতুন করে হিসাব হয়। দোকানে ১০টি অর্ডারে তাতে সমস্যা নেই। কিন্তু একটি বড় ই-কমার্স সাইটের কয়েক কোটি অর্ডার-লাইনের ওপর “পণ্যভিত্তিক মোট বিক্রি” প্রতিবার হিসাব করতে কয়েক মিনিট লাগতে পারে — আর dashboard-টি দিনে হাজারবার খোলা হয়। সমাধান: হিসাবটি একবার করে ফল ডিস্কে রেখে দেওয়া, তারপর সবাই সেই জমানো ফল পড়বে। এটিই materialized view: একটি view, যার ফল আসল টেবিলের মতো জমা থাকে।

জমানো ফল base table বদলালে নিজে থেকে বদলায় না। তাকে নতুন করে হিসাব করানোকে বলে refresh, আর refresh-এর আগের পুরোনো ফলকে বলে stale (বাসি) ডেটা। প্রধান DBMS-গুলোতে চেহারাটা এমন:

CREATE MATERIALIZED VIEW mv_product_sales AS
SELECT p.product_id, p.name, SUM(i.quantity) AS units_sold
FROM products p JOIN order_items i ON i.product_id = p.product_id
GROUP BY p.product_id, p.name;          -- এখনই চলে, ফল জমা হয়

SELECT * FROM mv_product_sales;         -- জমানো ফল পড়া, কোনো JOIN চলে না

REFRESH MATERIALIZED VIEW mv_product_sales;    -- পুরো ফল নতুন করে; চলার সময় পড়াও আটকে থাকে

CREATE UNIQUE INDEX ON mv_product_sales (product_id);
REFRESH MATERIALIZED VIEW CONCURRENTLY mv_product_sales;  -- পড়া চালু রেখে

-- base table-এর প্রতিটি পরিবর্তন একটি log-এ লেখা হবে
CREATE MATERIALIZED VIEW LOG ON order_items
  WITH ROWID, SEQUENCE (product_id, quantity) INCLUDING NEW VALUES;

CREATE MATERIALIZED VIEW mv_product_sales
  BUILD IMMEDIATE
  REFRESH FAST ON COMMIT           -- প্রতিটি COMMIT-এ শুধু পরিবর্তনটুকু বসাও
  ENABLE QUERY REWRITE             -- optimizer নিজে এটি ব্যবহার করতে পারে
AS SELECT product_id, SUM(quantity) AS units_sold,
          COUNT(quantity) AS cnt_qty, COUNT(*) AS cnt
   FROM order_items GROUP BY product_id;

CREATE VIEW dbo.product_sales WITH SCHEMABINDING AS
SELECT product_id, SUM(quantity) AS units_sold, COUNT_BIG(*) AS cnt
FROM dbo.order_items GROUP BY product_id;

-- unique clustered index বসালেই ফল জমা হয় (indexed view)
CREATE UNIQUE CLUSTERED INDEX ix_product_sales ON dbo.product_sales (product_id);

৮ · SQLite-এ materialized view-এর অনুকরণ আর stale ফল

SQLite-এ materialized view নেই, কিন্তু ধারণাটি সহজেই বানানো যায়। পর্ব ১৩-এর CREATE TABLE AS SELECT একটি কোয়েরির ফল দিয়ে আসল টেবিল বানায় — এটিই “materialize” করা। Refresh মানে পুরোনো সারি মুছে একই কোয়েরি দিয়ে আবার ভরা। নিচে একটি নতুন বিক্রির পর জমানো ফল আর আসল ডেটা কীভাবে আলাদা হয়ে যায়, দেখুন:

-- materialize: ফল একটি আসল টেবিলে
CREATE TABLE mv_product_sales AS
SELECT p.product_id, p.name, SUM(i.quantity) AS units_sold
FROM products p JOIN order_items i ON i.product_id = p.product_id
GROUP BY p.product_id, p.name;

-- নতুন বিক্রি: অর্ডার 1008-এ আরও ৩টি Headphone
INSERT INTO order_items VALUES (1008, 102, 3, 1200);

SELECT units_sold AS stored FROM mv_product_sales WHERE product_id = 102;
SELECT SUM(quantity) AS live FROM order_items WHERE product_id = 102;

-- refresh: মুছে, নতুন করে ভরা
DELETE FROM mv_product_sales;
INSERT INTO mv_product_sales
SELECT p.product_id, p.name, SUM(i.quantity)
FROM products p JOIN order_items i ON i.product_id = p.product_id
GROUP BY p.product_id, p.name;
SELECT units_sold AS after_refresh FROM mv_product_sales WHERE product_id = 102;

সাধারণ view আর materialized view-এর ফল সময়ের সাথে কীভাবে আলাদা হয়, একটি দিনের ঘটনাক্রমে দেখুন (Headphone-এর মোট বিক্রি):

শেষ ধাপের trigger-পদ্ধতিটি এবার চালিয়ে দেখুন। জমানো টেবিল product_sales-এ product_id primary key; trigger পর্ব ১৪-এর upsert (ON CONFLICT … DO UPDATE) দিয়ে নতুন পণ্য হলে সারি বানায়, পুরোনো হলে যোগ করে:

CREATE TABLE product_sales (product_id INTEGER PRIMARY KEY, units_sold INTEGER NOT NULL);
INSERT INTO product_sales
SELECT product_id, SUM(quantity) FROM order_items GROUP BY product_id;

-- প্রতিটি নতুন লাইনের সাথে জমানো ফল হালনাগাদ
CREATE TRIGGER sales_on_insert AFTER INSERT ON order_items
BEGIN
  INSERT INTO product_sales VALUES (NEW.product_id, NEW.quantity)
  ON CONFLICT (product_id) DO UPDATE SET units_sold = units_sold + NEW.quantity;
END;

INSERT INTO order_items VALUES (1008, 102, 3, 1200);   -- পুরোনো পণ্য
INSERT INTO order_items VALUES (1006, 103, 2, 1800);   -- আগে কখনো বিক্রি হয়নি

SELECT * FROM product_sales WHERE product_id IN (102, 103);

৯ · পারফরম্যান্সের ভুল ধারণা আর view দিয়ে অধিকার

“View দিলে কোয়েরি দ্রুত হয়” — না

অংশ ৩-এ দেখেছেন, সাধারণ view-এর কোয়েরি খুলে base table-এর কোয়েরি হয়ে যায়। তাই view নিজে থেকে কোনো কোয়েরিকে দ্রুত করে না — কোনো ফল আগে থেকে হিসাব করা নেই, কোনো index তৈরি হয়নি। ধীর কোয়েরিকে view-এ মুড়লে সেটি সমান ধীরই থাকে। উল্টো দিকে, view সাধারণত ধীরও করে না — যদি না view-এর ভেতরে এমন কিছু থাকে যা আপনার প্রশ্নের দরকার নেই। যেমন order_summary থেকে শুধু order_id আর status চাইলেও view-টি customers আর order_items-এর JOIN আর GROUP BY চালাবে। গতি চাইলে আসল হাতিয়ার index (পর্ব ৪০–৪১) আর materialized view; কোনটি কাজ করছে, তা বলবে query plan.

GRANT: শুধু view-এর অধিকার

অংশ ২-এর নিরাপত্তা আসল হয় privilege (অধিকার) দিয়ে। সার্ভার-DBMS-এ প্রতিটি ব্যবহারকারী বা role শুধু সেই টেবিল আর view পড়তে বা লিখতে পারে, যার অধিকার তাকে GRANT দিয়ে দেওয়া হয়েছে। কৌশলটি হলো: হিসাব শাখার role-কে customers টেবিলে কোনো অধিকার না দিয়ে শুধু public_customers view-এ SELECT দেওয়া। SQLite একটি ফাইল-ভিত্তিক embedded ডেটাবেস — ফাইলটি যে খুলতে পারে, সে সব পড়তে পারে — তাই সেখানে GRANT নেই; উদাহরণটি PostgreSQL-এর:

CREATE ROLE accounts_office LOGIN;
GRANT SELECT ON public_customers TO accounts_office;   -- শুধু view
-- customers টেবিলে কোনো GRANT নেই

-- accounts_office হিসেবে লগইন করে:
SELECT name, city FROM public_customers;   -- চলে
SELECT name, phone FROM customers;
-- ERROR:  permission denied for table customers

-- পর্ব ৫১-এর ঝলক: সারির স্তরে নিয়ম (row-level security)
ALTER TABLE customers ENABLE ROW LEVEL SECURITY;
CREATE POLICY dhaka_branch_only ON customers
  FOR SELECT TO dhaka_branch USING (city = 'Dhaka');

view কীভাবে customers পড়ে, যখন ব্যবহারকারীর নিজের সেই অধিকার নেই? কারণ PostgreSQL-এ view ডিফল্টভাবে base table পড়ে view-এর মালিকের অধিকারে (MySQL-এ একই ধারণার নাম SQL SECURITY DEFINER). PostgreSQL ১৫ থেকে WITH (security_invoker = true) দিয়ে উল্টোটা — যিনি পড়ছেন তাঁর অধিকারে — বেছে নেওয়া যায়। কলাম লুকানোর আরেকটি পথ কলামভিত্তিক GRANT: GRANT SELECT (customer_id, name, city) ON customers TO …. আর প্রতিটি শাখার জন্য আলাদা view না বানিয়ে একটি টেবিলেই সারিভিত্তিক নিয়ম বসানো যায় — row-level security, পর্ব ৫১-এ বিস্তারিত। মূল নীতিটি least privilege: যার যতটুকু কাজে লাগে, ঠিক ততটুকুই।

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

AI-কে “একটি রিপোর্টের view বানিয়ে দাও” বললে সে দ্রুত একটি সুন্দর CREATE VIEW লেখে, আর সেটি চলেও। কিন্তু view-এর ভুল একবার ঢুকলে প্রতিটি রিপোর্টে ছড়িয়ে পড়ে, কারণ সবাই সেটিই ব্যবহার করে। যা প্রায়ই দেখা যায়:

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

• view-এর SELECT-টি আলাদা চালিয়ে সারি-সংখ্যা base table-এর সাথে মিলিয়েছি (কেউ নীরবে বাদ পড়েনি, কেউ দুবার আসেনি)
• একটি-দুটি সারির মোট হাতে হিসাব করে view-এর মানের সাথে মিলিয়েছি
• ব্যবসার নিয়ম (বাতিল, ফেরত, পরীক্ষার অর্ডার) view-এর ভেতরে ঠিকভাবে লেখা আছে
• view-এর ওপর কোয়েরির EXPLAIN দেখেছি; অপ্রয়োজনীয় JOIN বা GROUP BY নেই
• materialized view হলে refresh-এর সময়সূচি আর কতটা পুরোনো ফল চলবে, লিখে রেখেছি
• নিরাপত্তার view হলে base table-এর অধিকার সত্যিই বন্ধ, পরীক্ষা করে দেখেছি