مطالب
بررسی دقیق عملکرد AutoMapper
همانطور که اطلاع دارید، AutoMapper ابزاری برای نگاشت خودکار بین Model و Dto می‌باشد؛ که به صورت نادرست تصور کاهش سرعت در استفاده کردن از آن، بین توسعه دهندگان جا افتاده‌است. در این مقاله قصد داریم به صورت دقیق، به بررسی سرعت عملکرد استفاده از AutoMapper و مقایسه آن با نگاشت دستی بپردازیم.
کد‌های کامل این قسمت را میتوانید از اینجا clone کرده و شخصا تست نمایید.

ابتدا یک پروژه‌ی Console Application را ساخته و AutoMapper را به همراه Ef6، نصب مینماییم. سپس دو کلاس جدید را به نام‌های User و Address به صورت زیر در پوشه‌ی Models مینویسیم.
using System.Collections.Generic;

namespace AutoMapperComparison.Models
{
    public class User
    {
        public int Id { get; set; }

        public string Name { get; set; }

        public ICollection<Address> Addresses { get; set; }
    }
}
using System.ComponentModel.DataAnnotations.Schema;

namespace AutoMapperComparison.Models
{
    public class Address
    {
        public int Id { get; set; }

        public double? Code { get; set; }

        public string Title { get; set; }

        public int UserId { get; set; }

        [ForeignKey(nameof(UserId))]
        public virtual User User { get; set; }
    }
}
بدیهی است که این دو مدل با همدیگر رابطه‌ی 1 به چند دارند. حال کافیست AppDbContext خود را به صورت زیر تعریف نماییم.
نکته: در متد Seed، برای ثبت رکورد‌های اولیه، از BulkInsert استفاده شده است (باید پکیج BulkInsert را نیز نصب نمایید)
using EntityFramework.BulkInsert.Extensions;
using System.Collections.Generic;
using System.Data.Entity;
using System.Data.SqlClient;

namespace AutoMapperComparison.Models
{
    public class AppDbContextInitializer : DropCreateDatabaseAlways<AppDbContext>
    {
        protected override void Seed(AppDbContext context)
        {
            User user = context.Users.Add(new User { Name = "Test" });

            context.SaveChanges();

            List<Address> addresses = new List<Address>();

            for (int i = 0; i < 500000; i++)
            {
                addresses.Add(new Address { Id = i, Code = 1, Title = "Test", UserId = user.Id });
            }

            context.BulkInsert(addresses);

            base.Seed(context);
        }
    }

    public class AppDbContext : DbContext
    {
        static AppDbContext()
        {
            Database.SetInitializer(new AppDbContextInitializer());

            //Database.SetInitializer<AppDbContext>(null);
        }

        public AppDbContext()
            : base(new SqlConnection(@"Data Source=.;Initial Catalog=AppDbContext;Integrated Security=True"), contextOwnsConnection: true)
        {
            Configuration.AutoDetectChangesEnabled = false;
            Configuration.EnsureTransactionsForFunctionsAndCommands = false;
            Configuration.LazyLoadingEnabled = false;
            Configuration.ProxyCreationEnabled = false;
            Configuration.ValidateOnSaveEnabled = false;
            Configuration.UseDatabaseNullSemantics = false;
        }

        public DbSet<User> Users { get; set; }

        public DbSet<Address> Addresses { get; set; }
    }
}
 برای اینکه مقایسه انجام شده دقیق باشد، تمامی Configuration‌های اضافی را نیز غیر فعال نموده‌ام.
فقط نیاز داریم یک Dto را برای Address نیز تعریف کنیم؛ چون قرار است نگاشت از Model به Dto از روی Address و AddressDto انجام شود.
کلاس AddressDto را به صورت زیر ایجاد میکنیم:
namespace AutoMapperComparison.Models
{
    public class AddressDto
    {
        public int Id { get; set; }

        public double? Code { get; set; }

        public string Title { get; set; }

        public int UserId { get; set; }

        public string UserName { get; set; }
    }
}
قرار است به صورت خودکار از طریق AutoMapper و همچنین به صورت دستی، نگاشت از Model به Dto مربوطه انجام شود.
 حال نیاز است فایل Program.cs را باز کرده و تغییرات زیر را اعمل نماییم:
using AutoMapper;
using AutoMapper.QueryableExtensions;
using AutoMapperComparison.Models;
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;

namespace AutoMapperComparison
{
    public class Program
    {
        public static void Main()
        {
            Mapper.Initialize(cfg =>
            {
                cfg.CreateMap<Address, AddressDto>();
            });

            Console.WriteLine($"Create Db {DateTimeOffset.UtcNow}");
            using (AppDbContext db = new AppDbContext())
            {
                db.Database.Initialize(force: true);
                db.Database.ExecuteSqlCommand("DBCC DROPCLEANBUFFERS"); //Removes all clean buffers from the buffer pool, and columnstore objects from the columnstore object pool
                Console.WriteLine(db.Addresses.ProjectTo<AddressDto>());
                Console.WriteLine(db.Addresses.Select(add => new AddressDto { Id = add.Id, Code = add.Code, Title = add.Title, UserId = add.UserId, UserName = add.User.Name }));
            }

            Console.WriteLine($"Normal Select {DateTimeOffset.UtcNow}");
            using (AppDbContext db = new AppDbContext())
            {
                db.Database.ExecuteSqlCommand("DBCC DROPCLEANBUFFERS");
                Stopwatch watch = Stopwatch.StartNew();
                List<AddressDto> addresses = db.Addresses.AsNoTracking().Select(add => new AddressDto { Id = add.Id, Code = add.Code, Title = add.Title, UserId = add.UserId, UserName = add.User.Name }).ToList();
                List<AddressDto> addresses2 = db.Addresses.AsNoTracking().Select(add => new AddressDto { Id = add.Id, Code = add.Code, Title = add.Title, UserId = add.UserId, UserName = add.User.Name }).ToList();
                watch.Stop();
                Console.WriteLine($"{watch.ElapsedMilliseconds} {addresses.Count} {addresses2.Count}");
            }

            Console.WriteLine($"AutoMapper Exec {DateTimeOffset.UtcNow}");
            using (AppDbContext db = new AppDbContext())
            {
                db.Database.ExecuteSqlCommand("DBCC DROPCLEANBUFFERS");
                Stopwatch watch = Stopwatch.StartNew();
                List<AddressDto> addresses = db.Addresses.AsNoTracking().ProjectTo<AddressDto>().ToList();
                List<AddressDto> addresses2 = db.Addresses.AsNoTracking().ProjectTo<AddressDto>().ToList();
                watch.Stop();
                Console.WriteLine($"{watch.ElapsedMilliseconds} {addresses.Count} {addresses2.Count}");
            }

            Console.ReadKey();
        }
    }
}
نکته: از دستور DBCC DROPCLEANBUFFERS جهت خالی کردن بافر sql server برای رسیدن به نتیجه‌ی هرچه دقیق‌تر استفاده شده است.
بعد از اجرا کردن، ابتدا بررسی میکنیم که کوئری اجرا شده‌ی دو نوع مختلف، هیچ تفاوتی با هم نداشته باشند.


حال نتایج بدست آمده، در قسمت پایین‌تر آن نمایان میشود:


البته نتیجه‌ی این آزمایش بسته به سخت افزار سیستم شما ممکن است کمی متفاوت باشد.

در سه آزمایش دیگر به صورت متوالی نتیجه‌ی زیر بدست آمد:

Normal   AutoMapper
 2451  2378
 2120  2111
 2202  2124

اگر این مقدار جزئی از تفاوت بین دو نوع مختلف آزمایش را مورد نظر نگیریم، میتوان گفت که هر دو روش نتیجه‌ی کاملا یکسانی خواهند داشت. فقط با استفاده از AutoMapper کد‌های کمتری نوشته شده‌است!

اما دلیل چیست؟ از آنجایی که ProjectTo از Dto به Model انجام شده و Lambda Expressionی که به سمت Entity Framework فرستاده شده‌است با روش Normal کاملا برابر است و بقیه‌ی عملیات توسط EF انجام میشود، با قاطعیت میتوان گفت که هر دو روش ذکر شده از نظر Performance کاملا یکسان خواهند بود.

نکته: البته به این موضوع باید توجه شود که اگر همین آزمایش را بطور مثال با استفاده از یک Listی از رکورد‌های درون Memory ساخته شده توسط خودمان انجام دهیم، آن موقع نتیجه‌ی یکسانی نخواهیم داشت، به دلیل اینکه EFی دیگر وجود نخواهد داشت که مسئولیت بازگشت داده‌ها را بر عهده بگیرد. از آنجائیکه اکثر کارهایی که توقع داریم AutoMapper برای ما انجام دهد، توسط ORM بازگشت داده میشود، پس میتوان گفت نکته‌ی فوق تقریبا در دنیای واقعی رخ نخواهد داد و باعث مشکل نخواهد شد.

مطالب
خواندنی‌های 23 فروردین

SubSonic یکی دیگر از ORM های تهیه شده برای دات نت فریم ورک است که توسط یکی از اعضای مایکروسافت هدایت می‌شود. این پروژه سورس باز و رایگان است.

گردآوری جالبی است؛ قابل توجه دوستانی که با php و سرورهای لینوکسی کار می‌کنند.

همانطور که مطلع هستید نگارش نهایی SP1 مربوط به SQL Server 2008 مدتی است که ارائه شده است و یکی از قابلیت‌های آن Slipstreaming نصب آن است (من ترجمه‌اش می‌کنم "نصب ممزوج"). منظور از آن هم این است که تمام پچ‌های قبلی را می‌شود با نصاب ابتدایی یکی کرد. (بنابراین نصب ممزوج معادل بدی نیست، "دایر کردن فرو رفتنی" هم به فرهنگستان پیشنهاد می‌شود :) )
برای مثال در SQL server 2005 شما مجبور هستید که ابتدا نگارش RTM آن‌را نصب کنید و بعد آخرین سرویس پک ارائه شده را، اما در حالت پشتیبانی از نصب ممزوج، می‌شود فایل‌های سرویس پک را مستقیما بر روی فایل‌های نصاب اولیه بازنویسی کرد و به این صورت با نصب آن، به یکباره SQL Server 2008 SP1 را خواهید داشت و دیگر نیازی به reboot های مکرر و توقف و راه اندازی سرویس‌های گوناگون ویندوز نیست (این مساله در یک سرور حائز اهمیت است).

نظرات مطالب
شروع به کار با EF Core 1.0 - قسمت 5 - استراتژهای تعیین کلید اصلی جداول و ایندکس‌ها
نمونه ای از نحوه پیاده سازی ROW_NUMBER در EF:
using System;
using System.Linq;
 
public class Test
{
public static void Main()
{
var beatles = (new[]
            {
                new {id = 1, inst = "guitar", name = "john"},
                new {id = 2, inst = "guitar", name = "george"},
                new {id = 3, inst = "guitar", name = "paul"},
                new {id = 4, inst = "drums", name = "ringo"},
                new {id = 5, inst = "drums", name = "pete"}
            });
 
            var result = beatles
                .GroupBy(g => g.inst)
                .Select(c => c.OrderBy(o => o.id).Select((v, i) => new { i, v }).ToList())
                .SelectMany(c => c)
                .Select(c => new { c.v.id, c.v.inst, c.v.name, rn = c.i + 1 })
                .ToList();
 
            Console.WriteLine("id | inst \t| name  \t| rn");
            foreach (var row in result)
            {
                Console.WriteLine($"{row.id}  | {row.inst}\t| {row.name}  \t| {row.rn}");
            }     
}
}
با این خروجی:
id | inst | name  | rn
1  | guitar| john  | 1
2  | guitar| george  | 2
3  | guitar| paul  | 3
4  | drums| ringo  | 1
5  | drums| pete  | 2
نظرات مطالب
افزودن یک DataType جدید برای نگه‌داری تاریخ خورشیدی - 1
با درود
New Project -> Database -> SQL Server -> Visual C# SQL CLR Database Project 
- تنظیمات اتصال به پایگاه داده ها 
- انتخاب دکمه Yes
- Add New Item -> User Defined Type 
- کپی کدها
- استفاده از Deploy در منوی Build یا استفاده از روشی که در بخش دوم نوشتار آموزش داده خواهد شد.
نظرات مطالب
ساخت یک Form Generator ساده در MVC
- برای دریافت اطلاعات یک فرم مشخص:
        public IList<Value> GetValues(int formId)
        {
            return _values.Include(x => x.Field)
                          .Where(value => value.FormId == formId)
                          .ToList();
        }
- این پروژه از دیدگاه دریافت اطلاعات از کاربر و همچنین تولید فرم پویا جالب است (صرفا قسمت UI آن). به لطف نبود ViewState، طراحی فرم‌های پویا در اینجا خیلی ساده‌تر است از وب‌فرم‌ها.
- اما از دیدگاه ذخیره سازی این اطلاعات پویا ... مشکل دارد. در طراحی بانک اطلاعاتی آن فرض شده‌است که برنامه مثلا فرم یک را دارد. این فرم یک، 10 فیلد پویا یا بیشتر را دارد. این 10 فیلد فقط یکبار توسط کاربر پر می‌شوند. اگر کاربر قرار باشد بار دوم این فرم یک را پر کند، امکان پذیر نیست. در کلاس Value آن که فقط محتوای یک فیلد را ذخیره می‌کند، مفهومی به نام ردیف سند جاری وجود ندارد. به ازای هر فیلد یک ردیف مجزا داریم؛ اما مشخص نیست این ردیف‌ها متعلق به کدام سند هستند (منظور از سند، شمار منحصربفرد پر کردن فرم جاری است؛ هر کاربر یک فرم را بیش از یکبار می‌تواند پر کند).
 برای حل این نوع مشکلات (برای اینکه به ازای مقدار هر فیلد فرم پویا، یک ردیف مجزا تولید نشود و schemaless کار کرد) یا باید از یک بانک اطلاعاتی NoSQL استفاده کرد که مثلا کل فرم را در قالب یک شیء JSON سریالایز کند و آن‌را داخل یک فیلد از یک ردیف (یک سند) ذخیره کند. یا اگر با SQL Server کار می‌کنید، فیلد XML آن چنین قابلیتی را دارد. کل اطلاعات دریافتی فرم را تبدیل به XML کنید و سپس ذخیره. به این صورت امکان تهیه کوئری و گزارش گرفتن‌های پیشرفته و بهینه را به همراه تعریف ایندکس و مسایل دیگر نیز خواهید داشت. اینبار هر ردیف بانک اطلاعاتی، مفهوم یک سند کامل را پیدا می‌کند؛ بجای اینکه هر ردیف فقط یک مقدار از یک فیلد باشد. همچنین در این حالت هر ردیف می‌تواند محتوای فرمی را ذخیره کند که با ردیف بعدی کاملا متفاوت است (بر اساس طراحی پویای متفاوت هر فرم).
نظرات مطالب
Protocol Buffers فرمتی برای تبادل دیتا
به این این دلیل گفتم خوب نیست چون برای موضوع جاری (استفاده از Protobuf و GRPC) خوب نیست و گرنه اگر موضوع مقاله "تبدیل Json RESTful به GRPC بود" قطعا این کتابخانه میتوانست بهترین باشد.
حالا چرا میگم خوب نیست؟ چون طبق تصویر زیر که از داکیومنت ریپازیتوریش برداشته شده و کاملا گویاست، grpc-gateway به عنوان یک Reverse Proxy درخواست‌های کلاینت را به GRPC تبدیل و ترجمه میکند و ارتباط Client با سرور همچنان Json RESTful بوده و پس عملا مزایای GRPC و Protobuf رو از بین میبره. اصلا اگر قراره همچنان ارتباط سرور با کلاینت RESTful باشه دیگه چرا GRPC ؟!

 ضمن اینکه الان کتابخانه third-party برای GRPC در اکثر زبان‌ها (# C++, Python, Ruby, Objective-C, PHP, C  و...) وجود داره پس مشکلی بابت عدم پشتیبانی نخواهیم داشت.
قطعا که Json RESTful به این زودی‌ها محبوبیت خودشو از دست نخواهد داد و grpc-gateway هم کاربرد خاص خودش رو خواهد داشت ولی عرض من این هست که با پوشاندن لباس Json RESTful به GRPC اون رو فلج نکنیم! مخصوصا زمانی که امکان استفاده از کتابخانه‌های GRPC رو در تمام کلاینت هامون داریم.


نظرات مطالب
Url Routing در ASP.Net WebForms
سلام.
این روتینگ رو تعریف میکنید.
 RouteTable.Routes.MapPageRoute("Gallery", "Page/{PageName}", "~/Main.aspx");
در صفحه‌ی Main.aspx
string pi = Page.RouteData.Values["PageName"] + "" ;
Pages page = (from p in context.Pages where p.PageName == pi select p).FirstOrDefault();
if (page ==  null )
        Response.Redirect("/");
  else
    // نمایش اطلاعات  
نظرات مطالب
اجرای وظایف زمان بندی شده با Quartz.NET - قسمت دوم
همانطور که عنوان شد طراحی دیتابیس است نه استفاده از ابزارهای جانبی. یک وبلاگ در این حالت شبیه به کوئری زیر کار می‌کند (هر فراخوانی صفحه‌ای معادل است با یک کوئری از بانک اطلاعاتی):
select * from tblPosts where (showDate is null) or (showDate<=getdate())
فیلد showDate اگر نال بود، یعنی یک مطلب معمولی است که درجا نمایش پیدا می‌کند. اگر تاریخی برای آن مشخص شده بود، بر اساس تاریخ جاری یک مقایسه صورت گرفته و رکوردها انتخاب و نمایش داده می‌شوند.
مطالب
بررسی کارآیی کوئری‌ها در SQL Server - قسمت هشتم - بررسی عملگرهای Merge Join و Sort در یک Query Plan
در یک merge join، اطلاعات از دو ورودی مرتب شده، دریافت و join می‌شوند. اگر این ورودی‌ها از پیش مرتب شده نباشند (دارای ایندکس مناسبی نباشند)، یک عملگر Sort در این میان تزریق خواهد شد. عملگر Sort نیز اندکی متفاوت است از سایر عملگرها. این عملگر یک iterator نیست (یعنی ردیف به ردیف عمل نمی‌کند) و اگر اطلاعاتی وارد آن شد، ابتدا باید کل آن مرتب شود و سپس به قسمت‌های بعدی ارسال گردد؛ که مصرف حافظه و I/O زیادی را به همراه دارد. به همین جهت جزو مواردی است که باید در یک کوئری پلن، بیشتر به آن دقت داشت.


بررسی عملگر merge join

 ابتدا در management studio از منوی Query، گزینه‌ی Include actual execution plan را انتخاب می‌کنیم. سپس کوئری‌های زیر را اجرا می‌کنیم:
USE [WideWorldImporters];
GO

SET STATISTICS IO ON;
GO

SELECT
    [p].[PurchaseOrderID],
    [pl].[PurchaseOrderLineID]
FROM [Purchasing].[PurchaseOrders] [p]
    JOIN [Purchasing].[PurchaseOrderLines] [pl]
    ON [p].[PurchaseOrderID] = [pl].[PurchaseOrderID];
GO
در اینجا اطلاعات دو جدول PurchaseOrders و PurchaseOrderLines بر روی ستون PurchaseOrderID با هم Join شده‌اند و اجرای آن یک چنین کوئری پلنی را تولید می‌کند:


در اینجا یک merge join انجام شده، چون اطلاعات رسیده‌ی به آن، از پیش مرتب شده‌است. از این جهت که جدول PurchaseOrders دارای یک clustered index تعریف شده‌ی بر روی PurchaseOrderID است:
ALTER TABLE [Purchasing].[PurchaseOrders] ADD  CONSTRAINT [PK_Purchasing_PurchaseOrders] PRIMARY KEY CLUSTERED
(
   [PurchaseOrderID] ASC
)
و همچنین جدول PurchaseOrderLines نیز دارای یک non-clustered index تعریف شده‌ی بر روی PurchaseOrderID است:
CREATE NONCLUSTERED INDEX [FK_Purchasing_PurchaseOrderLines_PurchaseOrderID] ON [Purchasing].[PurchaseOrderLines]
(
    [PurchaseOrderID] ASC
)
چون این دو ایندکس پیش‌فرض، اطلاعات از پیش مرتب شده‌ای را بر اساس PurchaseOrderID دارند، قابلیت تغذیه‌ی merge join را خواهند داشت.

اما بهینه سازی کوئری‌های SQL Server، همیشه در یک چنین شرایطی، از merge join استفاده نمی‌کند. برای مثال کوئری زیر نیز دقیقا از لحاظ تعریف ایندکس بر روی OrderID، وضعیت مشابهی با کوئری قبلی دارد:
SELECT
    [o].[OrderID],
    [ol].[OrderLineID]
FROM [Sales].[Orders] [o]
    JOIN [Sales].[OrderLines] [ol]
    ON [o].[OrderID] = [ol].[OrderID];
GO
اما کوئری پلن آن به صورت زیر است:


اگر به میزان ضخامت پیکان‌های این پلن، با پلن قبلی دقت کنید، مشاهده می‌کنید که ضخامت آن‌ها در اینجا افزایش یافته‌است. این افزایش ضخامت پیکان‌ها، بیانگر افزایش میزان اطلاعات ارسالی به قسمت‌های مختلف است (حدود 231 هزار ردیف) به همراه اسکن بالایی بر روی ایندکس [FK_Sales_Orders_SalespersonPersonID] است (بر روی PersonID بجای OrderID) و دومی بر روی [NCCX_Sales_OrderLines]. چون ایندکس OrderID سنگین است و تعداد ردیف زیادی را شامل می‌شود، بهینه ساز ترجیح داده‌است تا از ایندکس دیگری استفاده کند که I/O کمتری را به همراه دارد. در این‌حالت دیگر merger join میسر نبوده و از hash match استفاده کرده‌است.

اگر OrderID انتخاب شده را از جدول OrderLines تهیه کنیم، چه اتفاقی رخ می‌دهد؟ (در کوئری قبلی، OrderID از جدول Orders انتخاب شده بود)
SELECT
    [ol].[OrderID],
    [ol].[OrderLineID]
FROM [Sales].[Orders] [o]
    JOIN [Sales].[OrderLines] [ol]
    ON [o].[OrderID] = [ol].[OrderID];
در این حالت به کوئری پلن زیر خواهیم رسید:


یک بازنویسی ساده و دریافت دو ستون از یک جدول سبب شده‌است تا بهینه سازی کوئری، join تشکیل شده را غیرضروری دانسته و مستقیم عمل کند.


اهمیت مرتب شده بودن اطلاعات در تشکیل Joinهای بهینه

کوئری زیر را در نظر بگیرید که در آن یک select * را داریم (که یک ضد الگو است):
SELECT *
FROM [Sales].[Orders] [o]
    JOIN [Sales].[OrderLines] [ol]
    ON [o].[OrderID] = [ol].[OrderID];
GO
اجرای آن چنین کوئری پلنی را تولید می‌کند:


جدول OrderLines دارای یک non-clustered index، فقط بر روی ستون OrderID است؛ اما با select * نوشته شده، تمام ستون‌های آن‌را درخواست کرده‌ایم (و نه فقط OrderID را)؛ به همین جهت اطلاعات آن پیش از ارسال به merge join باید توسط عملگر sort مرتب شود و همانطور که مشاهده می‌کنید، هزینه‌ی این عملگر در این پلن، 82 درصد کل است.


تاثیر order by بر روی کوئری پلن تشکیل شده

دو کوئری زیر را در نظر بگیرید که تفاوت دومی با اولی، در داشتن یک ORDER BY است:
SELECT TOP 1000
    *
FROM [Sales].[OrderLines];
GO

SELECT TOP 1000
    *
FROM [Sales].[OrderLines]
ORDER BY [Description];
GO
پس از اجرای این دو کوئری با هم، به کوئری پلن زیر خواهیم رسید:


اولی، تمام clustered index را اسکن نمی‌کند و جائیکه 1000 ردیف را از آن بازگشت می‌دهد، متوقف می‌شود.
اما در دومی چون نیاز به مرتب سازی اطلاعات بر اساس یک ستون بوده‌است، عملگر sort مشاهده می‌شود. اسکن آن نیز بر روی کل اطلاعات است (پیکان مرتبط با آن، نسبت به پلن قبلی ضخیم‌تر است) و سپس آن‌ها را مرتب می‌کند.

برای بهبود این وضعیت، تعداد ستون‌های بازگشت داده شده را محدود کرده و سپس بر اساس آن‌ها، ایندکس صحیحی را طراحی می‌کنیم:
بنابراین اینبار بجای select *، تعداد مشخصی از ستون‌ها را بازگشت می‌دهیم:
SELECT
    [CustomerID],
    [OrderDate],
    [ExpectedDeliveryDate]
FROM [Sales].[Orders]
ORDER BY [CustomerID];
GO
همچنین یک non-clustered index را بر روی CustomerID که دو ستون OrderDate و ExpectedDeliveryDate را include می‌کند، تعریف می‌کنیم:
CREATE NONCLUSTERED INDEX [IX_Sales_Orders_CustomerID_Dates]
ON [Sales].[Orders](
[CustomerID] ASC
)
INCLUDE (
[OrderDate], [ExpectedDeliveryDate]
)
ON [USERDATA];
GO
اکنون اگر کوئری جدید محدود شده را اجرا کنیم، به کوئری پلن زیر خواهیم رسید که در آن خبری از عملگر sort نیست؛ چون ایندکس جدید تعریف و استفاده شده، کار مرتب سازی را نیز انجام داده‌است: