View — bir yoki bir nechta table, boshqa view yoki query natijasini virtual table sifatida taqdim etadigan database obyektidir. Oddiy view ko‘pincha ma’lumotni alohida saqlamaydi; unga murojaat qilinganda asosiy query bajariladi.
View murakkab queryni nomlash, accessni cheklash, barqaror interface yaratish va data modelini soddalashtirish uchun ishlatiladi.
View yaratish
Oddiy misol:
CREATE VIEW active_users AS
SELECT id, name, email
FROM users
WHERE deleted_at IS NULL;
Keyin:
SELECT *
FROM active_users;
querysi yoziladi.
Database view ta’rifini asosiy query bilan birlashtirib execution plan yaratishi mumkin.
Virtual table
View table kabi:
imkonini beradi.
Lekin oddiy view ichida rowlar mustaqil storage’da saqlanmaydi.
Asosiy table o‘zgarsa view natijasi keyingi queryda shu o‘zgarishni ko‘rsatadi.
Abstraction
View murakkab join va calculationni yashiradi.
Masalan:
orders
+ users
+ payments
+ products
asosida order_summary view yaratiladi.
Consumer har safar barcha join detallarini yozmaydi.
Bu query interface’ni barqarorlashtiradi.
Security
View userga table’dagi barcha fieldlarni emas, faqat ruxsat etilgan qismini ko‘rsatishi mumkin.
Masalan, employee table’dan:
- ID;
- ism;
- bo‘lim
ko‘rsatiladi, ammo:
- maosh;
- shaxsiy identifikator;
- ichki izoh
yashiriladi.
Base table permissioni olib tashlanib, faqat view uchun read huquqi berilishi mumkin.
Row filtering
View faqat ma’lum rowlarni ko‘rsatadi.
Masalan:
CREATE VIEW uz_orders AS
SELECT *
FROM orders
WHERE region = 'UZ';
Biroq view predicate’i barcha security holatida mustahkam boundary bo‘lishi uchun database’ning security modeliga mos sozlanishi kerak.
Application user arbitrary boshqa tablega kira olmasligi lozim.
Updatable view
Ayrim sodda view’lar orqali base table’ga insert, update yoki delete qilish mumkin.
Odatda view:
- bitta table;
- oddiy column mapping;
- aggregation yo‘q;
- distinct yo‘q;
- murakkab join yo‘q
bo‘lsa updatable bo‘lishi mumkin.
Aniq qoidalar database mahsulotiga bog‘liq.
Check option
Updatable view orqali yozilgan row view shartidan chiqib ketmasligi uchun CHECK OPTIONga o‘xshash qoida ishlatiladi.
Masalan, faqat active userlarni ko‘rsatuvchi view orqali active = false qilib yuborish cheklanishi mumkin.
Aks holda update muvaffaqiyatli bo‘lib, row view’dan darhol yo‘qoladi.
Materialized view
Materialized view query natijasini fizik saqlaydi.
Afzalliklari:
- murakkab aggregation tez o‘qiladi;
- katta join qayta-qayta bajarilmaydi;
- report va dashboard tezlashadi.
Kamchiligi — natija asosiy table bilan darhol sinxron bo‘lmasligi mumkin.
Refresh
Materialized view yangilanishi kerak.
Refresh usullari:
Refresh vaqtida read bloklanishi yoki qo‘shimcha storage talab qilinishi mumkin.
Freshness talabi aniq belgilanadi.
View dependency
View base table va boshqa view’larga bog‘liq.
Column rename yoki type o‘zgarishi view’ni buzishi mumkin.
Database dependency graph orqali ayrim DDL amallarni bloklashi yoki dependent obyektlarni cascade o‘chirishi mumkin.
Migrationdan oldin viewlar tekshiriladi.
Nested view
Bir view boshqa view’dan foydalanishi mumkin.
Bu abstractionni oshiradi, ammo ko‘p qatlamli nested view:
- query planni tushunish;
- performance tahlili;
- dependency;
- column lineage
ni murakkablashtiradi.
Har qatlam aniq maqsadga ega bo‘lishi kerak.
Query optimizer
Optimizer oddiy view ta’rifini tashqi query bilan birlashtirib filterlarni pastga surishi mumkin.
Masalan, tashqi WHERE sharti base table scani oldidan qo‘llanadi.
Ba’zi constructlar optimization barrier bo‘lishi mumkin.
Execution plan view nomini emas, haqiqiy operationlarni ko‘rsatadi.
Naming
View nomi uning business ma’nosini ifodalaydi.
Masalan:
active_customers;monthly_sales;public_profiles;pending_payments.
view1 yoki temp_data kabi nomlar ownership va semantikani tushuntirmaydi.
API stability
View database consumerlari uchun barqaror contract vazifasini bajarishi mumkin.
Base table qayta tuzilsa ham view eski column nomlari va formatini saqlaydi.
Bu legacy report yoki integrationni migration vaqtida himoya qiladi.
Ammo view cheksiz compatibility qatlamiga aylanib qolmasligi uchun deprecation rejasi kerak.
View va stored query
View query matnini markazlashtiradi.
Lekin parameter qabul qilmaydi.
Parameterli reusable logic uchun:
- table-valued function;
- procedure;
- application query;
- prepared statement
ishlatilishi mumkin.
Performance
View sekin yoki tez bo‘lishi uning nomiga emas, ichidagi query va outer filterga bog‘liq.
Tekshiriladi:
- join;
- index;
- aggregation;
- sort;
- nested view;
- statistics;
- materialization.
Oddiy view avtomatik cache degani emas.
Permission modeli
View owneri va caller huquqi qaysi contextda tekshirilishi database’ga bog‘liq.
Security-definerga o‘xshash model kuchli imkoniyat beradi.
Noto‘g‘ri search path yoki dynamic query privilege escalationga olib kelishi mumkin.
View replacement
View ta’rifi o‘zgarganda uning column nomi, tartibi va data type’i consumerlarga ta’sir qiladi.
Ayrim database’larda CREATE OR REPLACE VIEW mavjud viewni permissionlari bilan saqlab yangilaydi.
Biroq incompatible column o‘zgarishi uchun yangi view nomi yoki bosqichli migration kerak bo‘lishi mumkin.
View testing
View uchun row count, null, duplicate va business invariant testlari yoziladi.
Asosiy table’ga test data kiritilib view natijasi tekshiriladi.
Materialized view bo‘lsa refreshdan oldingi va keyingi freshness holati ham test qilinadi.
Bog‘liq tushunchalar
Database view, Virtual table, Materialized view, Query, Base table, Access control, Updatable view, Refresh, Query optimizer, Data abstraction