مقدمه

Standard View رایج‌ترین نوع View در SQL Server است و یک دستور SELECT نام‌گذاری‌شده را به‌صورت شیء پایگاه داده نگهداری می‌کند. این شیء معمولاً داده را جداگانه ذخیره نمی‌کند؛ هر بار که Query مصرف‌کننده اجرا می‌شود، Optimizer تعریف View را با Query بیرونی ترکیب می‌کند و برای جداول پایه طرح اجرا می‌سازد.

هدف اصلی Standard View ایجاد یک قرارداد پایدار و خوانا میان مدل فیزیکی داده و مصرف‌کننده است. تیم گزارش‌گیری می‌تواند از مجموعه ستون‌های کنترل‌شده استفاده کند، در حالی که جزئیات Join، Alias و برخی محاسبات در یک نقطه نگهداری می‌شوند.

این انتزاع نباید به پنهان‌کردن پیچیدگی بی‌حد تبدیل شود. Viewهای چندلایه و تو در تو، وابستگی را دشوار و بررسی Plan را سخت می‌کنند. طراحی خوب Grain هر ردیف، کلید منطقی، ستون‌های خروجی، قواعد NULL و مالک قرارداد را مستند می‌کند.

در این مقاله از ساخت ابتدایی تا فیلتر SARGable، امنیت، تازه‌سازی Metadata و سنجش کارایی پیش می‌رویم. برای دیدن جایگاه این نوع در کنار انواع دیگر، راهنمای جامع Views در SQL Server را نیز مطالعه کنید.

تعریف، Syntax و اجزای اصلی

تعریف زیر الگوی عمومی این موضوع را نشان می‌دهد. نام Schema را صریح بنویسید، فهرست ستون‌ها را کنترل کنید و Script را در Source Control نگه دارید تا انتشار در محیط‌های مختلف تکرارپذیر باشد.

CREATE [ OR ALTER ] VIEW [ schema_name. ]view_name
    [(column_alias [,...n])]
    [WITH ENCRYPTION | SCHEMABINDING | VIEW_METADATA]
    AS
    select_statement
    [WITH CHECK OPTION];

سازوکار و نکات فنی پیشرفته

عبارت CREATE VIEW باید نخستین دستور Batch باشد؛ به همین دلیل ابزارهای انتشار معمولاً قبل و بعد آن GO می‌گذارند. CREATE OR ALTER در نسخه‌های جدیدتر انتشار تکرارپذیر را ساده می‌کند، زیرا وجود یا نبود View را جداگانه کنترل نمی‌کنید.

View پارامتر ورودی ندارد. برای منطق پارامتری می‌توان Inline Table-Valued Function را بررسی کرد. اگر هدف اجرای چند مرحله، مدیریت خطا یا تغییر داده است، Stored Procedure غالباً قرارداد مناسب‌تری دارد.

Optimizer مرز Standard View را مانند یک دیوار قطعی نمی‌بیند. تعریف را Expand می‌کند، Predicateها را جابه‌جا می‌کند و Join Order را بر اساس آمار انتخاب می‌کند. بنابراین ایندکس جداول پایه و کیفیت Statistics تعیین‌کننده هستند.

WITH CHECK OPTION مانع می‌شود تغییر داده از طریق View ردیفی ایجاد کند که پس از تغییر دیگر در همان View دیده نمی‌شود. این گزینه برای Viewهای قابل Update مفید است، اما باید خطاهای حاصل در لایه برنامه مدیریت شوند.

SCHEMABINDING در Standard View اختیاری است و تغییر ناسازگار جدول پایه را مسدود می‌کند. حتی اگر قصد Indexed View ندارید، گاهی برای حفاظت قرارداد مهم مفید است؛ در مقابل فرایند Migration را سخت‌گیرانه‌تر می‌کند.

امنیت با GRANT SELECT روی View و حذف دسترسی مستقیم به جدول پایه ساده‌تر می‌شود. با این حال Ownership Chain، Schema Owner و Dynamic SQL باید بررسی شوند تا مسیر دورزدن مجوز ایجاد نشود.

ستون‌های مشتق‌شده نوع داده خود را از عبارت می‌گیرند. CAST صریح برای مقدار مالی، تاریخ و متن باعث می‌شود Metadata خروجی پایدار باشد و تغییر نوع یکی از عملوندها قرارداد مصرف‌کننده را ناخواسته عوض نکند.

پایش Standard View باید روی Queryهای مصرف‌کننده انجام شود، نه فقط SELECT ساده از View. پارامترها، Sort، Join بیرونی و تعداد ستون‌ها می‌توانند Plan کاملاً متفاوتی ایجاد کنند.

مثال‌های عملی

مثال 1: ساده‌ترین View انتخابی

یک View پایه ستون‌های موردنیاز کاتالوگ را با نامی پایدار در اختیار برنامه قرار می‌دهد. انتخاب صریح ستون‌ها از تغییر ناخواسته قرارداد خروجی جلوگیری می‌کند.

CREATE OR ALTER VIEW dbo.vw_ActiveProducts
    AS
        SELECT ProductID, ProductName, UnitPrice
        FROM dbo.Products
        WHERE IsActive = 1;
    GO
    SELECT ProductID, ProductName, UnitPrice
    FROM dbo.vw_ActiveProducts;

از SELECT * در تعریف View دوری کنید؛ ستون صریح وابستگی را روشن می‌کند و ریسک تغییر Schema را کاهش می‌دهد.

مثال 2: ساخت داده نمونه و گزارش سفارش

این نمونه جدول مستقل و چند ردیف ایجاد می‌کند تا رفتار Standard View بدون پیش‌نیاز قابل آزمایش باشد. مبلغ نهایی در خود View محاسبه می‌شود.

IF OBJECT_ID(N'dbo.ViewOrderDemo', N'U') IS NULL
    BEGIN
        CREATE TABLE dbo.ViewOrderDemo
        (
            OrderID int PRIMARY KEY,
            CustomerID int NOT NULL,
            Quantity int NOT NULL,
            UnitPrice decimal(12,2) NOT NULL
        );
        INSERT dbo.ViewOrderDemo VALUES
            (1, 10, 2, 150000.00), (2, 20, 3, 90000.00);
    END;
    GO
    CREATE OR ALTER VIEW dbo.vw_ViewOrderDemo
    AS
        SELECT OrderID, CustomerID,
               CAST(Quantity * UnitPrice AS decimal(18,2)) AS TotalAmount
        FROM dbo.ViewOrderDemo;
    GO
    SELECT * FROM dbo.vw_ViewOrderDemo;

عبارت محاسباتی در هر بار خواندن ارزیابی می‌شود. اگر فیلتر سنگین یا پرتکرار است، ستون محاسباتی Persisted یا طراحی ایندکس مناسب را نیز ارزیابی کنید.

مثال 3: تغییر نام ستون با Alias

گاهی نام ستون منبع برای API مناسب نیست. Alias در View یک قرارداد خواناتر می‌سازد، بدون آنکه نام فیزیکی ستون جدول تغییر کند.

CREATE OR ALTER VIEW dbo.vw_CustomerContact
    AS
        SELECT CustomerID,
               FullName AS CustomerName,
               MobileNumber AS Mobile
        FROM dbo.Customers;
    GO
    SELECT CustomerName, Mobile
    FROM dbo.vw_CustomerContact
    ORDER BY CustomerName;

Alias بخشی از Metadata خروجی View است. تغییر آن می‌تواند برنامه مصرف‌کننده را بشکند و باید مانند تغییر API مدیریت نسخه شود.

مثال 4: فیلتر SARGable در Query مصرف‌کننده

گزارش روزانه باید سفارش‌های یک بازه را بخواند. مقایسه مستقیم ستون تاریخ با مرز ابتدا و انتها معمولاً امکان Index Seek را بهتر از اعمال تابع روی ستون حفظ می‌کند.

DECLARE @FromDate date = '20260701';
    DECLARE @ToDate date = '20260801';
    SELECT OrderID, OrderDate, Amount
    FROM dbo.vw_OrderReport
    WHERE OrderDate >= @FromDate
      AND OrderDate < @ToDate;

نوشتن WHERE YEAR(OrderDate)=2026 ممکن است جست‌وجوی مؤثر را دشوار کند. مرز نیمه‌باز برای ستون datetime هم دقیق‌تر و هم ایندکس‌پذیرتر است.

مثال 5: ترکیب View با JOIN کنترل‌شده

نمای گزارش، نام مشتری را در کنار سفارش نمایش می‌دهد. کلیدهای Join باید ایندکس و یکتایی مناسب داشته باشند تا تکثیر ردیف ناخواسته رخ ندهد.

CREATE OR ALTER VIEW dbo.vw_OrderCustomer
    AS
        SELECT o.OrderID, o.OrderDate, o.Amount,
               c.CustomerID, c.FullName
        FROM dbo.Orders AS o
        INNER JOIN dbo.Customers AS c
            ON c.CustomerID = o.CustomerID;
    GO
    SELECT FullName, COUNT(*) AS OrderCount
    FROM dbo.vw_OrderCustomer
    GROUP BY FullName;

View تو در تو و Joinهای زنجیره‌ای تخمین Cardinality را دشوار می‌کنند. تعریف را ساده نگه دارید و طرح اجرای Query نهایی را بررسی کنید.

مثال 6: رفتار NULL با COALESCE

در فهرست مشتری ممکن است شماره همراه ثبت نشده باشد. COALESCE یک متن نمایشی برمی‌گرداند، اما باید تفاوت مقدار واقعی NULL و متن جایگزین را در قرارداد داده مستند کرد.

CREATE OR ALTER VIEW dbo.vw_CustomerDisplay
    AS
        SELECT CustomerID, FullName,
               COALESCE(MobileNumber, N'ثبت نشده') AS MobileDisplay
        FROM dbo.Customers;
    GO
    SELECT CustomerID, FullName, MobileDisplay
    FROM dbo.vw_CustomerDisplay;

اگر مصرف‌کننده باید نبود داده را تشخیص دهد، ستون خام را نیز نگه دارید. جایگزینی NULL با متن می‌تواند مرتب‌سازی، نوع داده یا منطق فیلتر را تغییر دهد.

مثال 7: View با TOP و ترتیب ظاهری

این مثال یک خطای رایج را نشان می‌دهد: ORDER BY داخل View تضمین نمی‌کند خروجی مصرف‌کننده مرتب باشد. ترتیب باید در SELECT نهایی درخواست شود.

CREATE OR ALTER VIEW dbo.vw_RecentOrders
    AS
        SELECT TOP (100) OrderID, OrderDate, Amount
        FROM dbo.Orders
        ORDER BY OrderDate DESC;
    GO
    SELECT OrderID, OrderDate, Amount
    FROM dbo.vw_RecentOrders
    ORDER BY OrderDate DESC, OrderID DESC;

الگوی TOP 100 PERCENT برای تحمیل ترتیب قابل اتکا نیست و Optimizer می‌تواند آن را حذف کند. هر مصرف‌کننده باید ORDER BY خودش را داشته باشد.

مثال 8: لایه امنیتی برای واحد سازمانی

کاربر گزارش‌گیری فقط ستون‌های عمومی کارکنان فعال را می‌بیند. مجوز روی View اعطا می‌شود و دسترسی مستقیم جدول برای نقش در نظر گرفته نمی‌شود.

CREATE OR ALTER VIEW dbo.vw_PublicEmployees
    AS
        SELECT EmployeeID, FullName, DepartmentID, JobTitle
        FROM dbo.Employees
        WHERE EmploymentState = N'فعال';
    GO
    GRANT SELECT ON dbo.vw_PublicEmployees TO HrReportReader;
    SELECT EmployeeID, FullName, JobTitle
    FROM dbo.vw_PublicEmployees
    WHERE DepartmentID = 4;

View ابزار مفیدی برای کمینه‌سازی دسترسی است، اما جایگزین Row-Level Security در سناریوهای وابسته به هویت هر کاربر نیست.

مثال 9: رفع خطای وابستگی پس از تغییر Schema

اگر نوع یا ساختار جدول پایه تغییر کند، Metadata یک View بدون SCHEMABINDING ممکن است نیاز به تازه‌سازی داشته باشد. روش اصلاح، اجرای فرمان استاندارد پس از ارزیابی سازگاری است.

EXEC sys.sp_refreshview N'dbo.vw_OrderReport';
    GO
    EXEC sys.sp_refreshsqlmodule N'dbo.vw_OrderReport';
    GO
    SELECT TOP (5) OrderID, OrderDate, Amount
    FROM dbo.vw_OrderReport
    ORDER BY OrderDate DESC;

تازه‌سازی کورکورانه جای Migration و آزمون را نمی‌گیرد. ابتدا وابستگی‌ها را با sys.sql_expression_dependencies و تست قرارداد خروجی بررسی کنید.

مثال 10: اندازه‌گیری کارایی و طراحی ایندکس پایه

برای View معمولی معمولاً ایندکس روی جدول‌های پایه اثر اصلی را دارد. Query واقعی را با آمار IO بررسی می‌کنیم و ایندکس را بر اساس Predicate و ستون‌های خروجی طراحی می‌کنیم.

SET STATISTICS IO ON;
    SELECT OrderID, OrderDate, Amount
    FROM dbo.vw_OrderReport
    WHERE CustomerID = 205
      AND OrderDate >= '20260101';
    SET STATISTICS IO OFF;
    GO
    CREATE INDEX IX_Orders_CustomerID_OrderDate
    ON dbo.Orders(CustomerID, OrderDate)
    INCLUDE (OrderID, Amount);

ایندکس پیشنهادی باید با بار نوشتن، اندازه جدول و Queryهای دیگر سنجیده شود. Actual Plan و Query Store شواهد بهتری از حدس بر اساس متن Query ارائه می‌کنند.

خطاهای رایج

خطاهای زیر در بازبینی کد، Migration و تحلیل Incident زیاد دیده می‌شوند. هر مورد باید به یک Test یا Guard در فرایند انتشار تبدیل شود، زیرا کشف آن پس از رشد داده یا تغییر نسخه پرهزینه‌تر است.

• استفاده از SELECT * و تغییر ناخواسته ترتیب یا Metadata ستون‌ها
• فرض نادرست درباره تضمین ORDER BY داخل View
• ساخت زنجیره طولانی از Viewهای تو در تو
• اعمال تابع روی ستون فیلتر و از دست دادن SARGability
• تکیه بر View برای امنیت در حالی که نقش روی جدول پایه مجوز دارد
• نادیده گرفتن نوع داده و تبدیل ضمنی در Join
• تغییر Schema بدون بررسی وابستگی‌ها و Regression Test
• انتظار پذیرش پارامتر مانند Stored Procedure
• استفاده از NOLOCK و پذیرش داده ناسازگار بدون تحلیل
• انتخاب ستون‌های بیشتر از نیاز و افزایش IO شبکه و حافظه

ملاحظات کارایی و بهینه‌سازی

ابتدا Query پرتکرار و معیار موفقیت را مشخص کنید: زمان پاسخ، CPU، Logical Reads یا تعداد اجرای هم‌زمان. سپس Baseline بگیرید تا تغییر View یا ایندکس قابل مقایسه باشد.

Actual Execution Plan نشان می‌دهد تعریف View چگونه باز شده و کدام Operator بیشترین هزینه واقعی را داشته است. اختلاف شدید Estimated و Actual Rows معمولاً به Statistics، توزیع داده یا Predicate پیچیده اشاره می‌کند.

فیلتر را تا جای ممکن روی ستون خام و با نوع داده همسان بنویسید. تبدیل ضمنی میان nvarchar و int یا datetime و date می‌تواند Seek را به Scan تبدیل کند.

ایندکس جدول پایه را بر اساس ستون‌های برابری، بازه، Join و خروجی طراحی کنید. INCLUDE می‌تواند Lookup را کم کند، اما ایندکس عریض هزینه نوشتن و فضا را بالا می‌برد.

Query Store تاریخچه Plan و Regression را نگه می‌دارد و برای مقایسه قبل و بعد انتشار View ارزشمند است. Force Plan را تنها پس از شناخت علت و با برنامه بازبینی به کار ببرید.

برای Viewهای پیچیده، جداکردن مراحل در جدول موقت داخل Stored Procedure گاهی تخمین بهتری می‌دهد؛ اما این تصمیم وابسته به بار است و نباید بدون Benchmark اجرا شود.

بهترین روش‌ها

1. فهرست ستون‌ها را صریح و قرارداد خروجی را نسخه‌بندی کنید.
2. Schema و نام هدف‌محور برای View انتخاب کنید.
3. Grain هر ردیف و کلید منطقی را در مستند فنی ثبت کنید.
4. از تاریخ‌های غیرمبهم و رشته‌های فارسی با پیشوند N استفاده کنید.
5. فیلتر بازه زمانی را نیمه‌باز و SARGable بنویسید.
6. مجوز را به Role بدهید، نه کاربران پراکنده.
7. وابستگی‌ها را پیش از Migration استخراج و آزمایش کنید.
8. Actual Plan و STATISTICS IO را با داده نماینده بررسی کنید.
9. Viewهای تو در تو را محدود و منطق تکراری را بازطراحی کنید.
10. برای استقرار، Smoke Test و Rollback Plan داشته باشید.

کاربردهای واقعی در پروژه

در سامانه فروش، View می‌تواند قرارداد میان OLTP و گزارش عملیاتی باشد؛ اما گزارش تحلیلی بسیار سنگین شاید به Replica خواندنی یا انبار داده نیاز داشته باشد. انتخاب باید از SLA و الگوی بار شروع شود.

در پروژه مالی، نوع decimal، قواعد NULL، تاریخ مؤثر و Audit اهمیت ویژه دارد. خروجی View باید با داده مرجع تطبیق داده و برای تغییر تعریف، Test مجموع و تعداد ردیف اجرا شود.

در سامانه چندمستاجری، صرف افزودن TenantID به View امنیت کامل نمی‌سازد. Session Context، Row-Level Security، مجوز Role و تست نشت میان Tenantها باید به‌صورت یک طراحی یکپارچه دیده شوند.

برای تحویل حرفه‌ای، Script ساخت و Rollback، تست صحت، Benchmark قبل و بعد، Plan نمونه، ماتریس مجوز و مستند Grain تهیه می‌شود. این بسته نگهداری بعدی و انتقال دانش به تیم عملیات را آسان می‌کند.

سؤالات متداول

1. Standard View دقیقاً چیست؟

یک شیء Schema-scoped است که تعریف SELECT را ذخیره می‌کند و معمولاً داده مستقل ندارد. خروجی آن هنگام اجرا از جداول یا Viewهای پایه محاسبه می‌شود.

2. چگونه یک View استاندارد بسازیم؟

CREATE VIEW یا CREATE OR ALTER VIEW را در Batch جدا بنویسید، ستون‌ها را صریح انتخاب کنید و پس از ساخت با حساب مصرف‌کننده و داده نماینده آزمایش کنید.

3. هزینه پیاده‌سازی View برای گزارش سازمانی چقدر است؟

هزینه به تعداد منابع، پیچیدگی امنیت، تست کارایی و قراردادهای مصرف وابسته است. برآورد حرفه‌ای پس از بررسی Queryها، حجم داده و SLA انجام می‌شود.

4. آیا برای بازطراحی View قدیمی می‌توان مشاوره گرفت؟

بله؛ تحلیل Query Store، Plan، وابستگی‌ها و مجوزها می‌تواند به برنامه اصلاح مرحله‌ای منجر شود تا ریسک توقف سامانه کم شود.

5. Standard View بهتر است یا Stored Procedure؟

برای منبع جدولی قابل Join و بدون پارامتر View مناسب است؛ برای پارامتر، چند مرحله و کنترل عملیات Procedure انعطاف بیشتری دارد.

6. چگونه پروژه ساخت View امن را سفارش دهیم؟

دامنه ستون‌ها، نقش‌ها، مصرف‌کنندگان، SLA و محیط تست را مشخص کنید. خروجی پروژه بهتر است شامل Script، تست مجوز، Benchmark و مستند قرارداد باشد.

7. چرا بعد از تغییر جدول View خروجی اشتباه دارد؟

ممکن است Metadata قدیمی یا قرارداد SELECT * عامل باشد. وابستگی را بررسی، ستون‌ها را صریح و در صورت سازگاری sp_refreshview را اجرا کنید.

8. چرا Query روی View کند است؟

علت می‌تواند Scan جدول پایه، تبدیل ضمنی، آمار نامناسب، Join پرحجم یا فیلتر غیر SARGable باشد. Actual Plan و IO علت واقعی را نشان می‌دهد.

9. بهترین روش نگهداری Standard View چیست؟

تعریف را در Source Control نگه دارید، Migration تکرارپذیر بسازید، تست قرارداد و Plan Regression اجرا کنید و مالک فنی تعیین کنید.

10. Standard View در چه نسخه‌هایی کار می‌کند؟

اصل CREATE VIEW در نسخه‌های قدیمی SQL Server موجود است، اما CREATE OR ALTER و برخی توابع داخل تعریف به نسخه وابسته‌اند. سطح Compatibility را هم کنترل کنید.

سؤالات مصاحبه SQL Server

سؤال 1: این نوع View چه مسئله‌ای را حل می‌کند؟

پاسخ باید هدف منطقی، امنیتی یا کارایی را با توجه به نوع View توضیح دهد و محدودیت‌های آن را نیز بیان کند.

سؤال 2: Optimizer با View چگونه رفتار می‌کند؟

باید تفاوت Expand شدن View معمولی، امکان استفاده از ایندکس View و حذف شاخه در Partitioned View را با Plan توضیح داد.

سؤال 3: چگونه صحت خروجی را آزمایش می‌کنید؟

تعداد ردیف، کلیدهای تکراری، مجموع‌های کنترلی، NULL، مرز تاریخ و مقایسه با Query مرجع باید در تست خودکار پوشش داده شوند.

سؤال 4: چه معیارهایی برای کارایی می‌گیرید؟

Duration، CPU، Logical Reads، Actual Rows، Memory Grant، TempDB، Blocking و برای ساختار مادی‌شده هزینه DML و Log مهم‌اند.

سؤال 5: چگونه تغییر Schema را منتشر می‌کنید؟

وابستگی‌ها استخراج، Migration و Rollback نوشته، قرارداد مصرف تست و انتشار مرحله‌ای با پایش Query Store انجام می‌شود.

سؤال 6: مهم‌ترین نشانه طراحی نامناسب چیست؟

Grain نامشخص، SELECT *، لایه‌های تو در تو، تبدیل ضمنی و نبود Baseline نشانه‌هایی هستند که باید پیش از تولید رفع شوند.

چک‌لیست نهایی

• هدف و مصرف‌کننده View مشخص است.
• Grain و کلید منطقی مستند شده است.
• ستون‌ها و نوع داده صریح هستند.
• وابستگی و Schema Owner کنترل شده‌اند.
• مجوز با اصل حداقل دسترسی تست شده است.
• همه مثال‌ها در محیط آزمایشی اجرا شده‌اند.
• Actual Plan و STATISTICS IO ثبت شده‌اند.
• پارامتر و مرزهای داده آزموده شده‌اند.
• Migration و Rollback در Source Control هستند.
• پایش پس از انتشار و مالک فنی تعیین شده است.

جمع‌بندی

این موضوع زمانی ارزش واقعی ایجاد می‌کند که مسئله مشخصی را با قرارداد روشن حل کند و نتیجه آن با داده و Plan اثبات شود. تعریف کوتاه View نباید پیچیدگی امنیت، Metadata و کارایی پشت آن را پنهان کند.

پیش از انتشار، صحت ردیف‌ها، مرزهای NULL و تاریخ، مجوز و Regression را کنترل کنید. پس از انتشار نیز Query Store و شاخص‌های عملیاتی را زیر نظر بگیرید تا فرض طراحی در بار واقعی تأیید شود.

برای مرور مقایسه و انتخاب مسیر مناسب به راهنمای جامع Views در SQL Server بازگردید.