1. Learning Outcomes#

2. सबसे पहले समस्या समझिए#

मान लीजिए आपके database में employees और departments tables हैं।

हर बार आपको active employees की यह information चाहिए:

• employee name
• department name
• salary

इसके लिए query कुछ ऐसी हो सकती है:

SELECT
    e.employee_id,
    e.employee_name,
    d.department_name,
    e.salary
FROM employees AS e
JOIN departments AS d
    ON e.department_id = d.department_id
WHERE e.status = 'Active';

Query गलत नहीं है।

लेकिन imagine कीजिए कि यही query:

• HR report में चाहिए,
• manager dashboard में चाहिए,
• payroll verification में चाहिए,
• किसी application API में चाहिए,
• और कई developers को बार-बार लिखनी पड़ रही है।

अब problem केवल query लिखने की नहीं है।

Problem है:

एक useful query को बार-बार repeat करना।

अगर query बड़ी हो जाए, joins बढ़ जाएँ, filters बढ़ जाएँ और business logic भी जुड़ जाए, तो repetition maintenance problem बन जाता है।

यहीं पर View useful होता है।

3. Definition#

सरल भाषा में:

View एक नाम दिया हुआ reusable query interface है।

आप एक useful SELECT query लिखते हैं और database में उसे एक नाम दे देते हैं।

इसके बाद उस पूरी query को बार-बार लिखने की जगह आप View के नाम पर SELECT चला सकते हैं।

उदाहरण के लिए:

SELECT *
FROM active_employee_details;

यह देखने में table query जैसा लगता है।

लेकिन active_employee_details जरूरी नहीं कि कोई physical table हो।

यह एक View हो सकता है।

4. View को stored query definition क्यों कहा जाता है?#

यह point बहुत important है।

Regular View के बारे में beginner अक्सर सोचता है:

"Database ने query का result कहीं अलग table में save कर दिया होगा।"

सामान्य View के case में यह mental model सही नहीं है।

Database मुख्य रूप से View की definition रखता है।

उदाहरण:

CREATE VIEW active_employee_details AS
SELECT
    employee_id,
    employee_name,
    department_id,
    salary
FROM employees
WHERE status = 'Active';

यहाँ View की definition इस SELECT query पर आधारित है।

Conceptually flow ऐसा समझिए:

इस visual में सबसे important बात यह है:

View और underlying data अलग-अलग independent copies नहीं हैं।

View base tables के current data के ऊपर काम करता है।

अगर employees table में data बदलता है, तो अगली बार View query करने पर result भी बदल सकता है।

एक अलग database feature जिसे कुछ systems में materialized view कहा जाता है, data physically store कर सकता है। वह अलग concept है। इस chapter में हमारा focus regular View पर है।

5. हमारा sample data#

आगे के examples के लिए मान लीजिए employees table में यह data है:

और departments table में:

इन tables का उपयोग हम अलग-अलग View examples में करेंगे।

6. पहला View बनाना#

हम केवल active employees दिखाने वाला View बनाना चाहते हैं।

सबसे पहले requirement clear करें:

हमें चाहिए:

• employee ID
• employee name
• department ID
• salary
• केवल active employees

अब View create करते हैं:

CREATE VIEW active_employees AS
SELECT
    employee_id,
    employee_name,
    department_id,
    salary
FROM employees
WHERE status = 'Active';

इस statement को दो हिस्सों में समझिए।

CREATE VIEW active_employees#

यह database से कहता है:

active_employees नाम का View बनाइए।

AS SELECT ...#

यह बताता है कि View किस query से define होगा।

यानी:

SELECT
    employee_id,
    employee_name,
    department_id,
    salary
FROM employees
WHERE status = 'Active';

इस query की logic View के पीछे रहती है।

7. View को table की तरह query करना#

View create हो जाने के बाद:

SELECT *
FROM active_employees;

Expected rows conceptually:

ध्यान दीजिए:

Ravi नहीं आया क्योंकि उसका status Inactive है।

अब View के ऊपर भी filter लगाया जा सकता है:

SELECT
    employee_name,
    salary
FROM active_employees
WHERE salary >= 60000;

Result:

यहाँ learner के लिए सबसे important observation है:

View query करने का अनुभव table query करने जैसा है।

आप View पर:

• columns select कर सकते हैं,
• filters लगा सकते हैं,
• sorting कर सकते हैं,
• और उसे दूसरी queries में use कर सकते हैं,

बशर्ते आपके DBMS में उस operation के लिए valid semantics और permissions हों।

8. Complex Query को View से सरल बनाना#

अब practical case देखते हैं।

मान लीजिए हमें employee के साथ उसका department name भी चाहिए।

बिना View:

SELECT
    e.employee_id,
    e.employee_name,
    d.department_name,
    e.salary
FROM employees AS e
JOIN departments AS d
    ON e.department_id = d.department_id
WHERE e.status = 'Active';

यह query बार-बार लिखना inconvenient हो सकता है।

हम इसे View में रख सकते हैं:

CREATE VIEW active_employee_details AS
SELECT
    e.employee_id,
    e.employee_name,
    d.department_name,
    e.salary
FROM employees AS e
JOIN departments AS d
    ON e.department_id = d.department_id
WHERE e.status = 'Active';

अब consumer query:

SELECT *
FROM active_employee_details;

Result:

अब application या report को join details जानने की जरूरत नहीं है।

वह simply View को query कर सकता है।

इसी कारण View को reusable query abstraction कहा जाता है।

9. Abstraction का simple meaning#

Abstraction शब्द सुनकर इसे complicated मत समझिए।

इसका simple meaning है:

अंदर की unnecessary complexity छिपाकर बाहर एक simpler interface देना।

उदाहरण के लिए View के consumer को शायद यह जानने की जरूरत नहीं:

• कितने tables join हुए,
• join condition क्या थी,
• कौन-सा status filter लगाया गया,
• कौन-से internal columns ignore हुए।

Consumer को बस यह पता हो सकता है:

SELECT *
FROM active_employee_details;

यही View का abstraction benefit है।

यह dependency relationship दिखाता है:

Application View के साथ काम कर सकता है, जबकि View underlying tables की structure और query logic को encapsulate करता है।

10. View के पीछे current data आता है#

यह concept बहुत important है।

मान लीजिए अभी Amit का salary 55000 है।

फिर base table में salary update होती है:

UPDATE employees
SET salary = 60000
WHERE employee_id = 101;

अब:

SELECT
    employee_name,
    salary
FROM active_employees
WHERE employee_id = 101;

View से मिलने वाली salary अब 60000 हो सकती है क्योंकि View underlying table के current data पर आधारित है।

View को अलग से manually refresh करने की जरूरत regular View के basic model में नहीं होती।

11. Selected Columns expose करना#

Views का एक practical use यह है कि consumer को केवल जरूरी columns दिखाए जाएँ।

मान लीजिए employees table में internal columns भी हैं, लेकिन reporting user को केवल यह चाहिए:

• employee ID
• employee name
• department ID

हम View बना सकते हैं:

CREATE VIEW employee_directory AS
SELECT
    employee_id,
    employee_name,
    department_id
FROM employees;

अब:

SELECT *
FROM employee_directory;

Consumer को View definition में शामिल columns ही दिखाई देंगे।

यह application interface को simple बना सकता है।

और unnecessary columns expose होने से बच सकते हैं।

लेकिन यहाँ एक important caution है।

इसलिए View को security architecture का useful part माना जा सकता है, लेकिन permissions को separately सही configure करना जरूरी है।

12. Selected Rows expose करना#

View केवल columns ही नहीं, rows भी filter कर सकता है।

उदाहरण:

CREATE VIEW active_hr_employees AS
SELECT
    employee_id,
    employee_name,
    salary
FROM employees
WHERE department_id = 30
  AND status = 'Active';

यह View केवल:

• HR department
• active employees

को represent करता है।

अब consumer:

SELECT *
FROM active_hr_employees;

Base table की पूरी population query करने की जरूरत नहीं है।

View predefined filtering rule provide कर रहा है।

13. Business Rule को एक जगह रखना#

मान लीजिए आपके organization में "active employee" का standard meaning है:

status = 'Active'

अगर हर developer अलग-अलग query लिखे, तो एक व्यक्ति यह लिख सकता है:

WHERE status = 'Active'

और दूसरा गलती से:

WHERE status <> 'Inactive'

दोनों हमेशा logically equivalent हों, यह जरूरी नहीं।

अगर standard reporting logic View में centrally define हो:

CREATE VIEW active_employees AS
SELECT
    employee_id,
    employee_name,
    department_id,
    salary
FROM employees
WHERE status = 'Active';

तो consumers reusable definition use कर सकते हैं।

इससे consistency improve हो सकती है।

लेकिन View में business logic डालते समय naming और documentation clear होना चाहिए। Hidden logic बहुत ज्यादा हो जाए तो समझना difficult हो सकता है।

14. View और Base Table की Dependency#

View हवा में exist नहीं करता।

वह underlying objects पर depend करता है।

उदाहरण:

CREATE VIEW employee_directory AS
SELECT
    employee_id,
    employee_name,
    department_id
FROM employees;

यह View employees table पर dependent है।

Dependency को ऐसे समझिए:

अगर underlying structure में ऐसा change हो जाए जो View definition को invalid कर दे, तो View fail कर सकता है या maintenance require कर सकता है।

उदाहरण के लिए यदि View जिस column पर depend करता है वह remove या incompatible तरीके से बदल दिया जाए, तो impact हो सकता है।

Exact behavior DBMS के अनुसार अलग हो सकता है।

15. SELECT * से View बनाते समय सावधानी#

Technically कुछ systems में आप ऐसा लिख सकते हैं:

CREATE VIEW employee_view AS
SELECT *
FROM employees;

लेकिन long-term maintainability के लिए explicit columns अक्सर बेहतर होते हैं:

CREATE VIEW employee_view AS
SELECT
    employee_id,
    employee_name,
    department_id,
    salary,
    status
FROM employees;

क्यों?

क्योंकि इससे View contract clearer होता है।

Developer तुरंत देख सकता है:

• View कौन-से columns expose कर रहा है,
• output shape क्या है,
• schema change का impact कहाँ पड़ सकता है।

16. क्या View में calculated columns हो सकते हैं?#

हाँ, View की defining SELECT query expressions use कर सकती है।

उदाहरण:

CREATE VIEW employee_salary_summary AS
SELECT
    employee_id,
    employee_name,
    salary,
    salary * 12 AS annual_salary
FROM employees
WHERE status = 'Active';

अब:

SELECT
    employee_name,
    annual_salary
FROM employee_salary_summary;

View consumer को calculation की पूरी expression repeat नहीं करनी पड़ती।

लेकिन याद रखें:

View convenient abstraction है।

हर calculation को View में डाल देना automatically अच्छा design नहीं होता।

Complexity समझने योग्य रहनी चाहिए।

17. क्या View में joins हो सकते हैं?#

हाँ।

हमने पहले employees और departments का join देखा।

CREATE VIEW employee_department_details AS
SELECT
    e.employee_id,
    e.employee_name,
    d.department_name,
    e.salary
FROM employees AS e
JOIN departments AS d
    ON e.department_id = d.department_id;

अब:

SELECT *
FROM employee_department_details;

consumer को join logic repeat नहीं करनी पड़ती।

यह reporting और reusable read queries में बहुत useful हो सकता है।

18. View को filter करने पर क्या होता है?#

मान लीजिए View पहले से active employees दिखाता है:

CREATE VIEW active_employees AS
SELECT
    employee_id,
    employee_name,
    department_id,
    salary
FROM employees
WHERE status = 'Active';

और फिर आप लिखते हैं:

SELECT *
FROM active_employees
WHERE salary > 60000;

Conceptually दो conditions apply हो रही हैं:

1. View definition के कारण employee active होना चाहिए।
2. Outer query के कारण salary 60000 से अधिक होनी चाहिए।

इसलिए View को एक frozen table copy समझना जरूरी नहीं है।

Database optimizer internally query को efficient form में process कर सकता है।

Exact optimization strategy DBMS-specific होती है।

19. Read-Only और Updatable View की Awareness#

अब एक important beginner confusion देखते हैं।

क्योंकि View table की तरह query होता है, learner सोच सकता है:

"तो क्या मैं हर View पर INSERT, UPDATE और DELETE भी कर सकता हूँ?"

उत्तर है:

हर View के लिए नहीं।

कुछ simple Views कई database systems में updatable हो सकते हैं।

उदाहरण के लिए, एक single base table पर आधारित simple View:

CREATE VIEW active_employee_basic AS
SELECT
    employee_id,
    employee_name,
    salary,
    status
FROM employees
WHERE status = 'Active';

कुछ DBMS में इस प्रकार के View के through update allowed हो सकता है, subject to database-specific rules.

लेकिन अगर View में:

• joins,
• aggregation,
• GROUP BY,
• DISTINCT,
• calculated grouped results,
• या दूसरी complex operations

हों, तो update behavior restricted या disallowed हो सकता है।

20. Updatable View rules vendor-specific क्यों हैं?#

SQL databases का core idea similar हो सकता है, लेकिन implementation details differ कर सकती हैं।

उदाहरण:

• PostgreSQL
• MySQL
• SQL Server
• Oracle
• SQLite

इन systems में View updateability के exact rules और supported features अलग हो सकते हैं।

इसलिए professional approach यह है:

1. View की query structure समझिए।
2. अपने DBMS की official rules check कीजिए।
3. application में update behavior assume मत कीजिए।
4. critical DML behavior test कीजिए।

इस chapter के लिए आपको detailed vendor-specific rule list memorize करने की जरूरत नहीं है।

आपको यह principle याद रहना चाहिए:

21. View बनाम Table#

दोनों को SELECT से query किया जा सकता है, इसलिए beginner के लिए confusion होना natural है।

Simple memory:

Table stores data. View presents data through a reusable query definition.

22. View बनाम Derived Table#

आपने subquery को FROM clause में use किया होगा।

उदाहरण:

SELECT
    x.department_id,
    x.avg_salary
FROM (
    SELECT
        department_id,
        AVG(salary) AS avg_salary
    FROM employees
    GROUP BY department_id
) AS x;

यहाँ:

(
    SELECT
        department_id,
        AVG(salary) AS avg_salary
    FROM employees
    GROUP BY department_id
)

एक derived table की तरह काम कर रहा है।

लेकिन इसका नाम x केवल current query में useful है।

अब उसी logic को reusable View बनाया जा सकता है:

CREATE VIEW department_salary_summary AS
SELECT
    department_id,
    AVG(salary) AS avg_salary
FROM employees
GROUP BY department_id;

फिर:

SELECT *
FROM department_salary_summary;

मुख्य difference:

23. Views को दूसरे Views पर बनाना#

Technically कई databases में एक View दूसरे View को reference कर सकता है।

उदाहरण:

पहला View:

CREATE VIEW active_employees AS
SELECT
    employee_id,
    employee_name,
    department_id,
    salary
FROM employees
WHERE status = 'Active';

दूसरा View:

CREATE VIEW high_paid_active_employees AS
SELECT
    employee_id,
    employee_name,
    salary
FROM active_employees
WHERE salary >= 60000;

यह convenient लग सकता है।

लेकिन अब dependency chain बन गई:

एक-दो meaningful layers समझने योग्य हो सकती हैं।

Problem तब शुरू होती है जब View nesting बहुत deep हो जाती है।

24. Excessive View Nesting की Problem#

Imagine कीजिए:

report_view

depends on:

department_view

जो depends on:

active_employee_view

जो depends on:

employee_base_view

जो फिर कई tables पर depend करता है।

अब final query छोटी दिखाई दे सकती है:

SELECT *
FROM report_view;

लेकिन अंदर की वास्तविक logic बहुत बड़ी हो सकती है।

इससे कई problems आ सकती हैं:

• query समझना difficult,
• debugging difficult,
• dependency impact trace करना difficult,
• performance issue का source ढूँढना difficult,
• business logic hidden हो जाना,
• schema change का impact समझना difficult।

25. View Performance के बारे में सही Mental Model#

एक common misconception है:

"View बना दिया, इसलिए query automatically fast हो जाएगी।"

यह सही rule नहीं है।

Regular View primarily abstraction and reusability देता है।

Database engine View की underlying query को process करता है।

Performance depend कर सकती है:

• underlying query,
• joins,
• filters,
• indexes,
• data volume,
• optimizer,
• nesting,
• DBMS behavior

पर।

इसलिए View को automatic performance optimization technique मत समझिए।

26. Practical Naming#

View का नाम meaningful होना चाहिए।

Weak names:

• v1
• view_data
• temp_view

Better examples:

• active_employees
• employee_department_details
• department_salary_summary
• customer_order_summary

नाम देखकर View का purpose roughly समझ आना चाहिए।

कुछ teams naming convention जैसे vw_ prefix use करती हैं, जबकि दूसरी teams नहीं करतीं।

यह organizational convention है, universal SQL requirement नहीं।

27. View Design करते समय Practical Checklist#

View बनाने से पहले यह सोचिए:

1. क्या query सच में reusable है?
2. क्या View consumer के लिए complexity कम करेगा?
3. क्या View का नाम purpose clearly बताता है?
4. क्या selected columns intentionally चुने गए हैं?
5. क्या hidden filters consumer को समझने चाहिए?
6. क्या View की dependency manageable है?
7. क्या View nesting unnecessary तो नहीं?
8. क्या updateability assume की जा रही है?
9. क्या performance को बिना measure किए improve हुआ मान लिया गया है?

यह thinking View को केवल syntax feature से useful design tool बनाती है।

28. Common Mistakes#

View को copied table समझना#

Regular View को सामान्यतः result की independent physical copy मत समझिए।

वह underlying data पर आधारित reusable query interface है।

हर View को updatable मान लेना#

Updatable behavior structure और DBMS rules पर depend करता है।

SELECT * का careless use#

Explicit columns View contract को clearer बना सकते हैं।

View के अंदर बहुत अधिक hidden logic डालना#

Consumer query छोटी हो सकती है, लेकिन maintenance कठिन हो सकती है।

View nesting की लंबी chain बनाना#

एक View दूसरे View पर, फिर तीसरा दूसरे पर—यह dependency debugging मुश्किल बना सकता है।

View को automatic performance feature समझना#

View readability और reuse improve कर सकता है; performance separately analyze करनी चाहिए।

View को complete security solution मान लेना#

Selected rows/columns expose करना useful है, लेकिन permissions और DBMS security behavior भी configure करना पड़ता है।

29. Interview Preparation#

30. Recap#

इस chapter से आपको ये core बातें याद रखनी हैं:

• View एक named reusable query abstraction है।
• View को SELECT query से define किया जाता है।
• Regular View को stored result copy की तरह नहीं, stored query definition की तरह समझना बेहतर है।
• View को table की तरह SELECT से query किया जा सकता है।
• View complex joins, filters और calculations को reusable बना सकता है।
• View selected rows और columns expose कर सकता है।
• View underlying tables या Views पर depend करता है।
• Base data बदलने पर View से दिखने वाला result बदल सकता है।
• हर View updatable नहीं होता।
• View updateability DBMS-specific rules पर depend करती है।
• Table data store करता है; View query-based representation देता है।
• Derived Table current query scope में useful होता है; View reusable database object होता है।
• Excessive View nesting hidden complexity पैदा कर सकती है।
• View readability बढ़ा सकता है, लेकिन automatically performance improve होने की guarantee नहीं है।