View در SQL Server

T-SQL | Reusable Query Contract و SCHEMABINDING

View یک Query نام‌گذاری‌شده است که می‌تواند Contract خواندن داده، ساده‌سازی Join و محدود کردن Columnهای قابل مشاهده را فراهم کند. View معمولی به‌خودی‌خود Cache یا ابزار Performance نیست.

متن این فصل با رویکرد مرجع فنی و قابل استفاده در پروژه واقعی تنظیم شده است؛ مثال‌ها در امتداد مدل StoreDb نوشته شده‌اند و اصطلاحات اصلی SQL Server و T-SQL به‌صورت یکدست به‌کار می‌روند.

1. مفاهیم و قراردادهای اصلی

View یک Query نام‌گذاری‌شده است که می‌تواند Contract خواندن داده، ساده‌سازی Join و محدود کردن Columnهای قابل مشاهده را فراهم کند. View معمولی به‌خودی‌خود Cache یا ابزار Performance نیست.

در طراحی پایگاه داده، Syntax تنها بخشی از مسئله است. نوع داده، Constraint، الگوی دسترسی، Transaction و هزینه اجرای Query باید هم‌زمان با نیاز Domain در نظر گرفته شوند.

2. ساختار و Syntax پایه

Viewهای مصرف‌شده توسط Application مانند Contract مدیریت می‌شوند. نام Columnها صریح و SELECT * پرهیز می‌شود تا تغییر Table به‌صورت ناخواسته Schema خروجی را تغییر ندهد.

CREATE OR ALTER VIEW dbo.vw_ProductCatalog
AS
SELECT
    p.Id AS ProductId,
    p.Name AS ProductName,
    p.Price,
    p.Stock,
    c.Name AS CategoryName
FROM dbo.Products AS p
LEFT JOIN dbo.Categories AS c ON c.Id = p.CategoryId;
GO

3. سناریوی StoreDb

View گزارش Customer فقط Columnهای موردنیاز Support را نمایش می‌دهد و داده‌های حساس دیگر را از Contract حذف می‌کند. Permission SELECT روی View می‌تواند مستقل از Table مدیریت شود.

نمونه‌های این فصل بر مدل فروشگاهی StoreDb بنا شده‌اند تا ارتباط مفاهیم میان فصل‌ها حفظ شود و Queryها در یک Context یکپارچه قابل بررسی باشند.

CREATE OR ALTER VIEW dbo.vw_CustomerSupport
AS
SELECT
    Id,
    FirstName,
    LastName,
    Mobile
FROM dbo.Customers;
GO

4. اصول طراحی و Performance

طراحی پایدار باید هم صحت داده و هم هزینه اجرای عملیات را پوشش دهد. انتخاب ساده‌تر زمانی ترجیح دارد که Contract داده را روشن‌تر و رفتار Optimizer را قابل پیش‌بینی‌تر نگه دارد.

• Viewهای Nested عمیق محدود شوند.
• Indexed View تنها پس از اندازه‌گیری انتخاب شود.
• Schema خروجی View پایدار و مستند باشد.
• Permission بر اساس Use Case قابل اعمال باشد.

5. خطاهای رایج و نکات ایمنی

دستورهای SQL می‌توانند مستقیماً داده و ساختار را تغییر دهند؛ بنابراین بازبینی Context، تعداد Rowهای هدف و اثر Transaction قبل از اجرای تغییرات اهمیت عملی دارد.

• فرض اینکه View همیشه Performance را بهتر می‌کند.
• SELECT * داخل View پایدار.
• Parameter انتظار داشتن از View.
• Nesting چندلایه بدون مشاهده Plan نهایی.

6. چک‌لیست نهایی فصل

• View Contract صریح دارد.
• CREATE OR ALTER برای Deployment قابل استفاده است.
• Security Use Case بررسی شده است.
• Viewهای Performance-critical Plan شده‌اند.

7. جمع‌بندی

خروجی این فصل باید به تصمیمی قابل اتکا در طراحی یا Query منجر شود؛ صحت داده، قابلیت نگهداری و رفتار Performance سه معیار ثابت برای ارزیابی نمونه‌ها هستند.