اشتراک‌ها
بررسی روش ساخت برنامه‌های چندمستاجری در ASP.NET Core

Jon P. Smith, author of Entity Framework Core in Action, explains what a multi-tenant app is and then digs into the things you need to do to make a multi-tenant app using ASP.NET Core with EF Core.

00:00 Countdown
02:19 Introduction and Community Links
18:25 What are multi-tenant web applications?
21:14 Single level multi-tenant demo
29:00 Partitioning tenants with EF Core QueryFilter
38:00 Admin features: creating users and tenants
43:00 Q&A
43:00 Hierarchical multi-tenant
59:00 How to get started
1:06:30 Database sharding and connection string management
1:16:30 Scaling with Azure SQL Elastic Pools
1:19:00 Conclusion
 

بررسی روش ساخت برنامه‌های چندمستاجری در ASP.NET Core
مطالب
توابع Window و مساله های آماری running total و runnning average
مقدمه و شرح مساله
توسط ویژگی‌های جدیدی که در نسخه 2012 به بحث window افزوده شد می‌توانیم مسالهای running total و running average را به شکل بهینه ای حل کنیم.
ابتدا این دو مساله را بدون بکارگیری ویژگی‌های جدید، حل نموده و سپس سراغ توابع جدید خواهم رفت.

قبل از هر چیزی لازم است جدول زیر ساخته شود و داده‌های نمونه در آن درج شود:
create table testTable
(
day_nbr integer not null primary key clustered,
value integer not null check (value > 0)
);
insert into testTable
values (10, 7), (20, 15), (30, 3), (40, 9), (50, 17), (60, 25), (70, 10);

مساله running total بسیار ساده است، یعنی جمع مقدار سطر جاری با مقادیر سطرهای قبلی (بر اساس یک ترتیب معین)
running average هم مشابه به running total هست با این تفاوت که میانگین مقادیر سطرجاری وسطرهای قبلی محاسبه می‌شود.


و نتیجه به صورت نمودار:



راه حل در SQL Server 2000
توسط دو correlated scalar subquery در ماده SELECT می‌توانیم مقادیر دو ستون مورد نظر با محاسبه کنیم:
select *,
       runningTotal = (select sum(value)
                         from testTable
                        where day_nbr <= t.day_nbr),
       runningAverage = (select avg(value)
                           from testTable
                          where day_nbr <= t.day_nbr)
  from testTable t;



اگر به نقشه اجرای این query نگاه کنید گره(عملگر) inner join دو بار بکار رفته است (به وجود دو subquery)، که این عدد در روش توابع تجمعی window به صفر کاهش پیدا خواهد کرد



راه حل در SQL Server 2005

توسط cross apply به سادگی می‌توانیم دو subquery که در روش قبل بود را به یکی کاهش دهیم:
select *
  from testTable t
       cross apply (select sum(value) as runningTotal,
                           avg(value) as runningAverage
                      from testTable
                     where day_nbr <= t.day_nbr)d;


این بار تنها یک عملگر inner join در نقشه اجرای query مشاهده می‌شود:

 


راه حل در SQL Server 2012
با اضافه شدن برخی از ویژگی‌های استاندارد به ماده OVER مثل rows و range شاهد بهبودی در عملکرد query‌ها هستیم.
یکی از کاربردهای توابع تجمعی window حل مساله running total و running average است.
به تصویر زیر توجه کنید، همانطور که در قبل توضیح دادم ما به سطرجاری و سطرهای پیشین نیاز داریم تا اعمال تجمعی (جمع و میانگین) را روی مقادیر بدست آمده انجام دهیم. در تصویر زیر سطرجاری و سطرهای قبلی به ازای هر سطری به وضوح قابل مشاهده است، مثلا هنگامی که سطر جاری برابر با روز 30 است ما خود سطر جاری (current row) و تمام سطرهای پیشین و قبلی (unbounded preceding) را نیاز داریم.


و اکنون query مورد نظر
select *, sum(value) over(order by day_nbr rows between unbounded preceding and current row) as runningTotal,
          avg(value) over(order by day_nbr rows between unbounded preceding and current row) as runningAverage
from testTable

در نقشه اجرای این query دیگر خبری از عملگر inner join نخواهد بود که به معنای عملکرد بهتر query است.
 

نظرات مطالب
شبیه سازی outer Join در entity framework
جهت تکمیل بحث، اگر مدل‌های برنامه به این صورت باشند (محل تولد اجباری است و Id کلید خارجی آن نال پذیر نیست؛ به همراه محل صدور اختیاری، که Id نال پذیر دارد):
    public class Place
    {
        public int Id { set; get; }
        public string Name { set; get; }

        public virtual ICollection<Person> Personnel { set; get; }
    }

    public class Person
    {
        public int Id { set; get; }
        public string FirstName { set; get; }
        public string LastName { set; get; }

        [ForeignKey("BirthPlaceId")]
        public virtual Place BirthPlace { set; get; }
        public int BirthPlaceId { set; get; }

        [ForeignKey("IssuanceLocationId")]
        public virtual Place IssuanceLocation { set; get; }
        public int? IssuanceLocationId { set; get; }
    }
با این Context :
public class MyContext : DbContext
    {
        public DbSet<Place> Places { get; set; }
        public DbSet<Person> Personnel { get; set; }

        public MyContext()
        {
            this.Database.Log = sql => Console.WriteLine(sql);
        }
    }
آنگاه خروجی کوئری ذیل (که یک include دارد روی خاصیت راهبری که مقدار Id کلید خارجی آن ممکن است نال باشد (محل صدور) و نه مورد دومی که Id غیرنال پذیر دارد (محل تولد))
context.Personnel.Include(x => x.IssuanceLocation)
معادل خواهد بود با (left outer join به صورت خودکار تشکیل شده)
SELECT
    [Extent1].[Id] AS [Id],
    [Extent1].[FirstName] AS [FirstName],
    [Extent1].[LastName] AS [LastName],
    [Extent1].[BirthPlaceId] AS [BirthPlaceId],
    [Extent1].[IssuanceLocationId] AS [IssuanceLocationId],
    [Extent2].[Id] AS [Id1],
    [Extent2].[Name] AS [Name],
    [Extent1].[Place_Id] AS [Place_Id]
    FROM  [dbo].[People] AS [Extent1]
    LEFT OUTER JOIN [dbo].[Places] AS [Extent2] ON [Extent1].[IssuanceLocationId] = [Extent2].[Id]

و خروجی کوئری زیر که DefaultIfEmpty را هم لحاظ کرده و join نویسی صریحی هم دارد (مطابق مقاله فوق):
var query = from personnel in context.Personnel
                            join issuanceLocation in context.Places on
                                  personnel.IssuanceLocationId equals issuanceLocation.Id into aIssuanceLocation
                            from IL in aIssuanceLocation.DefaultIfEmpty()
                            join birthLocation in context.Places on
                                  personnel.BirthPlaceId equals birthLocation.Id into aBirthLocation
                            from BL in aBirthLocation.DefaultIfEmpty()
                            select new
                               {
                                   personnel.Id,
                                   personnel.FirstName,
                                   personnel.LastName,
                                   IssuanceLocation = IL.Name,
                                   BirthLocation = BL.Name
                               };
معادل است با:
SELECT
                        [Extent1].[Id] AS [Id],
                        [Extent1].[FirstName] AS [FirstName],
                        [Extent1].[LastName] AS [LastName],
                        [Extent2].[Name] AS [Name],
                        [Extent3].[Name] AS [Name1]
                        FROM [dbo].[People] AS [Extent1]
                        LEFT OUTER JOIN [dbo].[Places] AS [Extent2] ON [Extent1].[IssuanceLocationId] = [Extent2].[Id]
                        INNER JOIN [dbo].[Places] AS [Extent3] ON [Extent1].[BirthPlaceId] = [Extent3].[Id]
و البته این خروجی دوم فقط در صورتی تشکیل می‌شود که قسمت select new ذکر شود. در غیراینصورت مشکل select n+1 را پیدا می‌کند و اصلا چنین join ایی تشکیل نخواهد شد (در یک حلقه، به ازای هر شخص، یکبار کوئری select به جدول مکان‌ها تشکیل می‌شود). همچنین یک inner join هم علاوه بر left outer join تشکیل شده (برای فیلد غیرنال پذیر).
حتی همین حالت دوم را هم با کوئری ذیل که از خواص راهبری استفاده کرده، می‌توان تولید کرد:
var query = context.Personnel.Select(x => new
             {
              x.Id,
              x.FirstName,
              x.LastName,
              BirthPlaceName = x.BirthPlace.Name,
              IssuanceLocationName = x.IssuanceLocation == null ? "" : x.IssuanceLocation.Name
             });
با این خروجی SQL (به صورت خودکار برای فیلد نال پذیر، left outer join و برای غیر نال پذیر inner join تشکیل داده)
SELECT
    [Extent1].[Id] AS [Id],
    [Extent1].[FirstName] AS [FirstName],
    [Extent1].[LastName] AS [LastName],
    [Extent2].[Name] AS [Name],
    CASE WHEN ([Extent3].[Id] IS NULL) THEN N'' ELSE [Extent3].[Name] END AS [C1]
    FROM   [dbo].[People] AS [Extent1]
    INNER JOIN [dbo].[Places] AS [Extent2] ON [Extent1].[BirthPlaceId] = [Extent2].[Id]
    LEFT OUTER JOIN [dbo].[Places] AS [Extent3] ON [Extent1].[IssuanceLocationId] = [Extent3].[Id]
مطالب
کوئری نویسی در EF Core - قسمت سوم - جوین نویسی
پس از آشنایی با نوشتن یک سری کوئری‌های ساده در EF Core، در این قسمت به نحوه‌ی گزارشگیری از اطلاعات چندین جدول مرتبط به هم توسط Joinها خواهیم پرداخت.

مثال 1: یافتن زمان‌های شروع رزرو کردن امکانات مختلف، توسط یک کاربر مشخص.

چگونه می‌توان زمان‌های شروع رزروهای کاربری به نام «David Farrell» را یافت؟


همانطور که در دیاگرام فوق مشاهده می‌کنید، به ازای هر ID کاربری در جدول کاربران، به دنبال ردیف‌هایی در جدول Bookings هستیم که این ID در آن‌ها درج شده‌است. اما ... در EF-Core برخلاف SQL نویسی معمولی، ما کاری به ذکر قسمت اتصالی ON [Bookings].[MemId] = [Members].[MemId] نداریم. همینقدر که در کوئری نوشته شده به یک سر دیگر رابطه و خاصیت راهبری (navigation property) دیگری اشاره شود، خود EF-Core جوینی را به صورت خودکار تشکیل خواهد داد و شرط یاد شده را نیز برقرار می‌کند.
در قسمت اول این سری، در حین طراحی موجودیت کاربر، برای تشکیل سر دیگر رابطه‌ی one-to-many آن، به جدول Bookings، خاصیت Member را نیز که بیانگر کلید خارجی به جدول کاربران است، اضافه کردیم:
namespace EFCorePgExercises.Entities
{
    public class Booking
    {
       // ...

        public int MemId { set; get; }
        public virtual Member Member { set; get; }

       // ...
    }
}
خاصیت عددی MemId، کلید خارجی است که در بانک اطلاعاتی رابطه‌ای ثبت خواهد شد و خاصیت Member، خاصیت راهبری است که جوین نویسی به جدول کاربران را بدون ذکر صریح جوین میسر می‌کند:
var startTimes = context.Bookings
                        .Where(booking => booking.Member.FirstName == "David"
                                            && booking.Member.Surname == "Farrell")
                        .Select(booking => new { booking.StartTime })
                        .ToList();
در این کوئری همینقدر که در قسمت Where آن booking.Member ذکر شده، جوینی به جدول کاربران را به صورت خودکار تشکیل می‌دهد:




مثال 2: یافتن زمان‌های شروع به رزرو شدن یک امکان خاص در مجموعه.
لیست زمان‌های شروع به رزرو شدن زمین(های) تنیس را برای روز 2012-09-21 تولید کنید. خروجی آن باید به همراه ستون‌های StartTime, FacilityName باشد.

طراحی موجودیت Booking، به همراه یک کلید خارجی به Facility نیز هست:
namespace EFCorePgExercises.Entities
{
    public class Booking
    {
       // ...

        public int FacId { set; get; }
        public virtual Facility Facility { set; get; }

       // ...
    }
}
خاصیت عددی FacId، کلید خارجی Facility است که در بانک اطلاعاتی رابطه‌ای ثبت خواهد شد و خاصیت Facility، خاصیت راهبری است که جوین نویسی به جدول Facilities را بدون ذکر صریح جوین میسر می‌کند:
int[] tennisCourts = { 0, 1 };
var date1 = new DateTime(2012, 09, 21);
var date2 = new DateTime(2012, 09, 22);
var startTimes = context.Bookings
                        .Where(booking => tennisCourts.Contains(booking.Facility.FacId)
                                && booking.StartTime >= date1
                                && booking.StartTime < date2)
                        .Select(booking => new { booking.StartTime, booking.Facility.Name })
                        .ToList();
- زمین‌های تنیس این مجموعه، دارای دو Id مساوی 0 و 1 هستند که در اینجا به صورت صریحی مشخص شده‌اند تا مانند مثال 6 قسمت قبل عمل شود. روش دیگر یافتن آن‌ها می‌تواند مانند مثال 5 قسمت قبل باشد که به صورت «Name.Contains("Tennis")» نوشته شد.
- در قسمت Where این کوئری چون booking.Facility ذکر شده، سبب ایجاد جوین خودکاری به جدول Facilities خواهد شد.
- علت استفاده‌ی از دو تاریخ در اینجا برای یافتن اطلاعات تنها یک روز، ثبت زمان، به همراه تاریخ رزرو است. ستون تاریخ شروع، به صورت «2012-09-21 18:00:00.0000000» مقدار دهی شده‌است و نه به صورت «2012-09-21». البته در EF-Core راه دیگری هم برای حل این مساله وجود دارد. هر خاصیت از نوع DateTime، به همراه خاصیت Date نیز هست. برای مثال اگر بجای booking.StartTime نوشته شود booking.StartTime.Date (به خاصیت Date اضافه شده دقت کنید)، کد SQL حاصل، به همراه «CONVERT(date, [b].[StartTime])» خواهد بود که سبب حذف خودکار قسمت زمان این ستون می‌شود.



مثال 3: تولید لیست کاربرانی که کاربر دیگری را توصیه کرده‌اند.

چگونه می‌توان لیست کاربرانی را یافت که کاربر دیگری را توصیه کرده‌اند؟ این لیست نباید به همراه ردیف‌های تکراری باشد و همچنین باید بر اساس surname, firstname مرتب شود.

در اینجا به مفهوم جوین کردن یک جدول با خودش رسیده‌ایم. جدول کاربران، یک جدول خود ارجاع دهنده‌است:
namespace EFCorePgExercises.Entities
{
    public class Member
    {
       // ...

        public virtual ICollection<Member> Children { get; set; }
        public virtual Member Recommender { set; get; }
        public int? RecommendedBy { set; get; }

       // ...
    }
}
که در اینجا RecommendedBy، یک کلید خارجی نال پذیر است که به Id همین جدول اشاره می‌کند. دو خاصیت دیگر تعریف شده، مکمل این خاصیت عددی، جهت سهولت کوئری نویسی‌های EF-Core هستند. برای مثال اگر در کوئری Recommender != null ذکر شود، سبب تشکیل جوینی به همین جدول شده و لیست کاربرانی را ارائه می‌دهد که کاربر دیگری را توصیه کرده‌اند:
var members = context.Members
                        .Where(member => member.Recommender != null)
                        .Select(member => new { member.Recommender.FirstName, member.Recommender.Surname })
                        .Distinct()
                        .OrderBy(member => member.Surname).ThenBy(member => member.FirstName)
                        .ToList();
وجود Distinct سبب بازگشت ردیف‌هایی غیرتکراری می‌شود (چون دو خاصیت نام و نام خانوادگی انتخاب شده‌اند، ردیف غیرتکراری، ردیفی خواهد بود که هر دوی این ستون‌ها در آن وجود نداشته باشد) و روش مرتب سازی بر اساس دو خاصیت را نیز مشاهده می‌کنید. در اینجا نباید دوبار OrderBy را پشت سر هم ذکر کرد. بار اول OrderBy است و بار دوم ThenBy تعریف می‌شود:



مثال 4: تولید لیست کاربران به همراه توصیه کننده‌ی آن‌ها.

چگونه می‌توان لیست کاربران را به همراه توصیه کننده‌ی آن‌ها تولید کرد؟ این لیست باید بر اساس surname, firstname مرتب شود.
var members = context.Members
                        .Select(member => new
                        {
                            memFName = member.FirstName,
                            memSName = member.Surname,
                            recFName = member.Recommender.FirstName ?? "",
                            recSName = member.Recommender.Surname ?? ""
                        })
                        .OrderBy(member => member.memSName).ThenBy(member => member.memFName)
                        .ToList();
در اینجا نیز می‌توان با ذکر member.Recommender سبب تولید یک جوین خودکار شد. همچنین همانطور که در مثال 7 قسمت قبل نیز بررسی کردیم، می‌توان بر روی خواص ذکر شده‌ی در Select، محاسباتی را نیز انجام داد. برای مثال در اینجا بجای درج مقدار null برای کاربرانی که کاربر دیگری را توصیه نکرده‌اند، ترجیح داده‌ایم که یک رشته‌ی خالی بازگشت داده شود که به صورت «COALESCE ([m0].[FirstName], N'')» ترجمه می‌شود:


همانطور که ملاحظه می‌کنید، نوع جوین خودکار تشکیل شده، Left join است و دیگر مانند جوین‌های مثال‌های ابتدای بحث، inner join نیست. در inner join، جدول سمت راست و چپ بر اساس شرط ON آن‌ها با هم مقایسه شده و ردیف‌های کاملا تطابق یافته‌ای بازگشت داده می‌شوند. کار Left join نیز مشابه است، با این تفاوت که در اینجا ممکن است برای جدول سمت چپ، هیچ ردیف تطابق یافته‌ای در جدول سمت راست وجود نداشته باشد (نوع آن بر اساس نال پذیری خاصیت RecommendedBy تشخیص داده شده‌است)؛ برای مثال یک کاربر ممکن است توسط کاربر دیگری توصیه نشده باشد (و RecommendedBy او نال باشد)، اما علاقمندیم که نام او در لیست نهایی حضور داشته باشد و حذف نشود.


یک نکته: در SQL Server تفاوتی بین left join و left outer join وجود ندارد و ذکر واژه‌ی کلیدی outer کاملا اختیاری است. جدول موارد مشابهی در SQL Server که به یک معنا هستند، صورت زیر است:
A LEFT JOIN B            A LEFT OUTER JOIN B
A RIGHT JOIN B           A RIGHT OUTER JOIN B
A FULL JOIN B            A FULL OUTER JOIN B
A INNER JOIN B           A JOIN B


مثال 5: تولید لیست کاربرانی که از زمین تنیس استفاده کرده‌اند.

چگونه می‌توان لیست کاربرانی را تولید کرد که از زمین(های) تنیس استفاده کرده‌اند؟ خروجی این گزارش باید به همراه یک ستون جمع نام و نام خانوادگی و ستون نام زمین باشد. این گزارش نباید دارای ردیف‌های تکراری باشد و همچنین باید بر اساس حاصل جمع نام و نام خانوادگی، مرتب شده باشد.

جدول Bookings به همراه دو کلید خارجی به جداول Facilities و Members است:
namespace EFCorePgExercises.Entities
{
    public class Booking
    {
       // ...

        public int FacId { set; get; }
        public virtual Facility Facility { set; get; }

        public int MemId { set; get; }
        public virtual Member Member { set; get; }

       // ...
    }
}
بنابراین برای تولید گزارشی که اطلاعات هر دوی این‌ها را به همراه دارد (اطلاعات کاربر و اطلاعات امکاناتی که استفاده کرده)، نیاز است دو جوین به دو جدول یاد شده نوشته شود. برای اینکار نیاز است در کوئری خود به booking.Member و booking.Facility برسیم. به همین جهت از جدول کاربران که دارای خاصیت از نوع ICollection  اشاره کننده‌ی به Bookings کاربران است شروع می‌کنیم:
namespace EFCorePgExercises.Entities
{
    public class Member
    {
       // ...

        public virtual ICollection<Booking> Bookings { set; get; }
    }
}
سپس بر روی این خاصیت مجموعه‌ای، اینبار یک SelectMany را فراخوانی می‌کنیم تا خروجی آن، تک تک رکوردهای booking متناظر باشد. اکنون که به هر رکورد booking کاربران دسترسی یافته‌ایم، می‌توانیم از طریق خواص راهبری booking.Member و booking.Facility هر ردیف، اطلاعات نهایی گزارش را تولید کنیم:
int[] tennisCourts = { 0, 1 };
var members = context.Members
                        .SelectMany(x => x.Bookings)
                        .Where(booking => tennisCourts.Contains(booking.Facility.FacId))
                        .Select(booking => new
                        {
                            Member = booking.Member.FirstName + " " + booking.Member.Surname,
                            Facility = booking.Facility.Name
                        })
                        .Distinct()
                        .OrderBy(x => x.Member)
                        .ToList();
ID زمین‌های تنیس مشخص هستند که توسط tennisCourts.Contains به FacId‌های موجود اعمال شده‌اند. همچنین در قسمت Select نیز خاصیت Member آن به جمع دو خاصیت از booking.Member اشاره می‌کند و چون نتیجه‌ی حاصل یک ستون از پیش تعریف شده نیست، نیاز است تا برای آن نام صریحی انتخاب شود.
پس از آن برای حذف ردیف‌های تکراری حاصل از گزارش، از متد Distinct استفاده شده و OrderBy نیز بر اساس خاصیت جدید Member، قابل تعریف است:



مثال 6: تولید لیست رزروهای گران قیمت

لیست رزروهای روز 2012-09-14 را تولید کنید که هزینه‌ی آن‌ها بیشتر از 30 دلار باشد. باید بخاطر داشت که هزینه‌های کاربران با مهمان‌ها متفاوت است و هزینه‌ها بر اساس Slotهای نیم ساعته محاسبه می‌شوند و ID کاربر مهمان همیشه صفر است. خروجی  این گزارش باید به همراه نام کامل کاربر، نام امکانات مورد استفاده و هزینه‌ی نهایی باشد. همچنین باید بر اساس هزینه‌های نهایی به صورت نزولی مرتب شود.
var date1 = new DateTime(2012, 09, 14);
var date2 = new DateTime(2012, 09, 15);

var items = context.Members
                        .SelectMany(x => x.Bookings)
                        .Where(booking => booking.StartTime >= date1 && booking.StartTime < date2
                        && (
                            (((booking.Slots * booking.Facility.GuestCost) > 30) && (booking.MemId == 0)) ||
                            (((booking.Slots * booking.Facility.MemberCost) > 30) && (booking.MemId != 0))
                        ))
                        .Select(booking => new
                        {
                            Member = booking.Member.FirstName + " " + booking.Member.Surname,
                            Facility = booking.Facility.Name,
                            Cost = booking.MemId == 0 ?
                                        booking.Slots * booking.Facility.GuestCost
                                        : booking.Slots * booking.Facility.MemberCost
                        })
                        .Distinct()
                        .OrderByDescending(x => x.Cost)
                        .ToList();
در اینجا نیز چون نیاز است خروجی نهایی به همراه نام کاربر و نام امکانات مورد استفاده باشد، همانند مثال قبلی، به حداقل دو جوین نیاز است. به همین جهت از جدول Members به همراه SelectMany بر روی تک تک Bookings آن شروع می‌کنیم.
سپس بر اساس صفر بودن یا نبودن booking.MemId  (کاربر مهمان بودن یا خیر)، شرط هزینه‌ی بیشتر از 30 دلار اعمال شده‌است.
در آخر Select گزارش مورد نیاز، به همراه جمع نام و نام خانوادگی، نام امکانات استفاده شده و خاصیت محاسباتی Cost است که بر اساس مهمان بودن یا نبودن کاربر، متفاوت است.
متد Distinct ردیف‌های تکراری حاصل از این گزارش را حذف می‌کند (محل درج آن مهم است) و متد OrderByDescending، مرتب سازی نزولی بر اساس خاصیت محاسباتی Cost را انجام می‌دهد.



مثال 7: تولید لیست کاربران به همراه توصیه کننده‌ی آن‌ها، بدون استفاده از جوین.

در اینجا می‌خواهیم همان مثال 4 را بدون استفاده از جوین بررسی کنیم. بدون استفاده از جوین در اینجا به معنای استفاده از sub-query است (نوشتن یک کوئری داخل کوئری اصلی).
var members = context.Members
                        .Select(member =>
                        new
                        {
                            Member = member.FirstName + " " + member.Surname,
                            Recommender = context.Members
                                .Where(recommender => recommender.MemId == member.RecommendedBy)
                                .Select(recommender => recommender.FirstName + " " + recommender.Surname)
                                .FirstOrDefault() ?? ""
                        })
                        .Distinct()
                        .OrderBy(member => member.Member)
                        .ToList();
این کوئری به صورت متداولی بر روی جدول Members اعمال شده‌است، با این تفاوت که در حین Select نهایی آن، یکبار دیگر کوئری جدید شروع شده‌ی با context.Members را مشاهده می‌کنید که سبب تولید یک sub-query، زمانیکه ToList نهایی فراخوانی می‌شود، خواهد شد. این sub-query در حقیقت یک outer join را با ذکر recommender.MemId == member.RecommendedBy (بیان صریح روش اتصال ID‌های دو سر رابطه) شبیه سازی می‌کند.



مثال 8: تولید لیست رزروهای گران قیمت با استفاده از یک sub-query.

هدف از این مثال، ارائه‌ی روش حل دیگری برای مثال 6، به نحو تمیزتری است. در مثال 6، هزینه‌ی رزرو را دوبار، یکبار در متد Where و یکبار در متد Select محاسبه کردیم. اینبار می‌خواهیم با استفاده از sub-query‌ها این محاسبه را یکبار انجام دهیم.
var date1 = new DateTime(2012, 09, 14);
var date2 = new DateTime(2012, 09, 15);

var items = context.Members
                        .SelectMany(x => x.Bookings)
                        .Where(booking => booking.StartTime >= date1 && booking.StartTime < date2)
                        .Select(booking => new
                        {
                            Member = booking.Member.FirstName + " " + booking.Member.Surname,
                            Facility = booking.Facility.Name,
                            Cost = booking.MemId == 0 ?
                                        booking.Slots * booking.Facility.GuestCost
                                        : booking.Slots * booking.Facility.MemberCost
                        })
                        .Where(x => x.Cost > 30)
                        .Distinct()
                        .OrderByDescending(x => x.Cost)
                        .ToList();
اینبار یک Select نوشته شده که در آن Cost، در ابتدا محاسبه شده و سپس Where دومی ذکر شده که از این Cost استفاده می‌کند.
هرچند کوئری SQL نهایی تولید شده‌ی توسط EF-Core آن، تفاوتی چندانی با نگارش قبلی ندارد:



کدهای کامل این قسمت را در اینجا می‌توانید مشاهده کنید.
نظرات مطالب
مشکل همزمانی خواندن و به روز رسانی اطلاعات در برنامه‌های وب
ممنون بابت مطلب خوب تون، در ادامه صحبت‌های شما خواستم چند مورد رو اضافه کنم

1- مشکل مطرح شده اصطلاحا Lost Update نام داره (که در مثال جاری باعث میشه یکی از بروزرسانی‌های عمل خرید گم بشه!)
این مشکل توسط Isolation Level سطوح Repeatable Read و Serializable قابل حل هست. 
جدول زیر لیست مشکلات همزمانی به ازای هر سطح از Isolation Level رو نشون میده.


2- استفاده از سطح Isolation Level بالاتر به معنی سخت گیری و احتیاط بیشتر هست و باعث افزایش میزان Blocking و متعاقبا احتمال وقوع Deadlock و نیز کاهش Performance و ظرفیت Concurrency (همزمانی) دیتابیس میشه (و بلعکس)
پس اگر مشکلی رو تونستین با Isolation Level سطح پایین‌تری مثل Repeatable Read حل کنید بهتره نسبت به اینکه Isolation Level سطح بالا‌تری مثل Serializable رو انتخاب کنین
 در تصویر زیر نحوه حل اش با Isolation Level سطح Repeatable Read رو مشاهده میکنین


3- برخلاف روش‌های دیگه، استفاده از Isolation Level سطح Repeatable Read و نیز Serializable در مثال جاری میتونه باعث وقوع Deadlock (بن بست) بشه و این بستگی به این داره که 2 تراکنش در چه نقطه ای به همزمانی میخورن
همونطور که در 2 تصویر زیر میبینین WAITFOR DELAY اولی باعث قوقع Deadlock میشه ولی دومی نمیشه
مثال وقوع Deadlock

توضیح:
اجازه بدید قبل از توضیح چرایی وقوع Deadlock مروری بر چیستی اون داشته باشیم
این مشکل زمانی پیش میاد که 2تا تراکنش مانع اجرای هم دیگه میشن و در بن بستی گیر میکنن که هیچ کدوم نمیتونن کارشون رو تموم کن. به عنوان مثال تراکنش اول قفل A رو به دست میگیره و منتظر آزاد شدن قفل B میشه در حالی که تراکنش دوم قفل B رو به دست گرفته و منتظر آزاد شدن قفل A میشه، در این حالت هر دو تراکنش منتظر اتمام کار یکدیگر هستند و در بن بستی گیر میکنن (Deadlock) که هیچ کدوم نمتونن کارشون رو تموم کنن
در این شرایط SQL Server به ناچار یکی از اون‌ها (در واقع تراکنشی که Rollback اش هزینه کمتری داره) رو به عنوان Victim (قربانی) حساب میکنه و اون رو  Rollback و سپس Kill میکنه تا حداقل دیگری بتونه به کارش ادامه بده

در Isolation Level سطح Serializable و Repeatable Read هر رکوردی که خونده (SELECT) بشه، از تغییر (UPDATE و DELETE) شدن همون رکورد توسط دیگر تراکنش‌ها جلوگیری میشه مادامی که تراکنش اول کارش تموم بشه
پس ترکنش اول مقدار balance رو SELECT میکنه، در همین حال تراکنش دوم نیز مقدار balance رو SELECT میکنه
سپس تراکنش اول میخواد مقدار balance رو UPDATE کنه ولی Block (مسدود) میشه چرا کنه همین رکورد قبلا توسط تراکنش دوم قفل شده، پس منتظر (Wait) تراکنش دوم میشه 
تراکنش دوم نیز میخواد مقدار balance رو UPDATE کنه و این هم Block (مسدود) میشه چرا کنه همین رکورد قبلا توسط تراکنش اول قفل شده، پس منتظر (Wait) تراکنش اول میشه و BOOM !! بن بست یا Deadlock رخ میده، چرا که هر دو تراکنش Block یکدیگه شدن و منتظر آزاد شدن قفل توسط دیگری هستند 

مثال عدم وقوع Deadlock

توضیح:
در این حالت اما تراکنش اول عمل SELECT و UPDATE رو زودتر از تراکنش دوم انجام میده و عمل UPDATE اش توسط تراکنش دوم بلاک (Block) نمیشه چرا که تراکنش دوم هنوز شروع نشده
دقت داشته باشین که در این مثال از WAITFOR TIME استفاده نکردیم که بخواد دقیقا در یک زمان مشخص، هر دو تراکنش رو اجرا بکنه بلکه چون دستی داریم کوئری‌ها رو اجرا میکنیم، همین تاخیر یک ثانیه ایی باعث میشه تراکنش اول کارش رو زودتر شروع کنه و فقط در میانه راه و بعد از عمل UPDATE به همزمانی بخورن

4- هینت HOLDLOCK معادل Isolation Level سطح Serializable هست، برای استفاده از سطح Repeatable Read میتونیم از هینت REPEATABLEREAD استفاده کنیم
صرفا جهت مرور:
عبارات Table Hints دستور هایی هستند که رفتار پیشفرض Query Optimizer (بهینه ساز کوئری) رو به هنگام دستورات DML (مثل SELECT/INSERT/UPDATE/DELETE) تغییر میده (override میکنن) و معمولا برای تغییر سطح قفل و Isolation Level و یا انتخاب Index دلخواه استفاده میشه


5- هینت UPDLOCK دو تا کار انجام میده
1- باعث میشه به جای قفل Shared Lock یا (S) از قفل Update Lock یا (U) بر روی رکورد‌های خوانده شده استفاده بشه
2- همانند سطح Repeatable Read و Serializable (هینت HOLDLOCK) قفل رو تا اتمام Trasanction (و نه صرفا Statement) نگه میداره (Hold میکنه) 
پس در این مثال خاص (و نه همه جا، که دلیل اون رو جلوتر بررسی میکنیم) میتونیم بدون HOLDLOCK هم انجامش بدیم و نیازی به اون نخواهیم داشت.
هینت UPDLOCK معمولا زمانی استفاده میشه که میخوایم رکورد یا رکورد هایی رو  در Statement‌های بعدی تراکنش جاری UPDATE کنیم و نمی‌خوایم در این بین تراکنش همزمان دیگری این دیتا رو تغییر بده


6- دقت داشته باشین که این تصور که چون UPDLOCK و HOLDLOCK هر دو در نگه داشتن (Hold کردن) قفل تا انتهای تراکنش (و نه Statement جاری) مشترک هستند پس به هنگام استفاده از UPDLOCK دیگر نیازی به HOLDLOCK نداریم تصور اشتباهی هست و علت ظریفی داره
یا بهتره این سوال رو اینطور مطرح کنیم که: 
پس چرا استفاده از  HOLDLOCK در کنار UPDLOCK رایج هست؟ و چه فرقی میکنه که HOLDLOCK در کنار UPDLOCK استفاده بکنیم یا خیر؟

قبل از بررسی چرایی این موضوع بهتره مروری بر روی Repeatable Read و Serializable از منظر Lock Mode‌ها (حالات قفل) داشته باشیم

سطح Repeatable Read
در این سطح قفل Shared صرفا به ازای رکورد‌های SELECT شده ایجاد میشه ولی برخلاف Read Committed قفل رو تا اتمام Transaction نگه میداره داره (Hold میکنه) - (نه به محض اتمام Statement)
در نتیجه تا پایان تراکنش جاری  از هر گونه تغییر بر روی دیتای Read شده توسط دیگر تراکنش‌های همزمان جلوگیری میکنه

سطح Serializable
این سطح مشابه سطح Repeatable Read عمل میکنه (یعنی قفل رو تا اتمام تراکنش و نه صرفا Statement جاری نگه میداره) با این تفاوت که از قفل Key-Range Lock به جای Shared Lock استفاده میکنه (البته نه همیشه و استثنا هایی هم وجود داره که جلوتر بررسی میکنیم) و کل بازه (محدوده) رکورد‌های SELECT شده بر اساس شرط WHERE رو قفل گذاری میکنه (بر خلاف Repeatable Read که صرفا به ازای رکورد‌های SELECT شده قفل ایجاد میکرد)
و بدین صورت از مشکل Phantom Read (مانند INSERT شدن رکورد جدیدی در بازه/محدوده قفل شده) جلوگیری میشه
به عنوان مثال در Serializable شرط WHERE Age BETWEEN 18 AND 35 یک قفل Key-Range Lock بر روی بازه (محدوده) 18 تا 35 گذاشته میشه و تمامی اعداد داخل این بازه رو شامل میشه (حتی اگه هیچ رکوردی در این بازه نداشته باشیم) در صورتی که Repeatable Read چون صرفا به ازای رکورد‌های SELECT شده قفل گذاری میشه، که اگه فرض کنیم هیچ رکوردی در این بازه نداریم، هیچ قفلی هم ایجاد نخواهد شد

بررسی نحوه عملکرد Serializable و استثنا‌های اون
در سطح Serializable بر اساس یکی از حالات زیر قفل ایجاد میشه
1- قفل Shared یا (S) روی کل Table
اگه جدول Index ایی نداشته باشه بر روی کل Table قفل Shared Lock یا (S) میگذاره (فرقی هم نمیکنه شرط WHERE داشته باشیم یا نه)
2- قفل Shared یا (S) روی رکورد (Row/Key)‌های Read شده
اگه شرط WHERE مون بر روی یک ستون Index باشه و مستقیما با مقدار مقایسه کنه (مثل عملگر  = یا IN) روی رکورد (Row/Key)‌های Read شده قفل Shared Lock یا (S) میگذاره
3- قفل RangeS-S روی رکورد (Row/Key)‌های Read شده
اگه شرط WHERE مون بر روی یک ستون Index باشه و دستوراتی که بازه (محدوده) رو مقایسه میکنن (مثل عملگر < و > و... یا BETWEEN) روی سطح رکورد (Row/Key) قفل Key-Range Lock یا (RangeS-S) میگذاره
4- قفل RangeS-S روی تمام رکورد‌ها (حتی Read نشده)
اگه شرط WHERE نداشته باشیم یا شرط WHERE مون بر روی یک ستون Index نباشه روی تمام رکورد‌ها (Row/Key) حتی Read نشده، قفل Key-Range Lock یا (RangeS-S) میگذاره

حال بر گردیم به سوال اولمون
در نکته قبلی (شماره 5) دیدیم که در این مثال «خاص» میتونیم بدون استفاده از HOLDLOCK در کنار UPDLOCK کارمون رو انجام بدیم
اما چی چیزی این مسئله رو «خاص» کرده؟
چون شرط WHERE مون بر روی Index جدول (یعنی فیلد user_id) هست و با عملگر (=) که مستقیما مقایسه میکنه (و نه در یک بازه - محدوده)
پس صرفا بر روی رکورد‌های Read شده (SELECT شده) قفل Shared Lock یا (S) گذاشته میشه دقیقا مانند کاری که Repeatable Read انجام میده (پس در این مورد خاص، سطح Repeatable Read و Serializable فرقی با هم ندارن)
همچنین گفتیم که هینت UPDLOCK هم عمل قفل گذاری رو صرفا بر روی رکورد‌های Read شده ایجاد میکنه (پس در این مثال خاص کاملا مشترک و شبیه هستند) و به همین دلیل هست که میتونیم بدون نیاز به HOLDLOCK در کنار UPDLOCK به همون نتیجه برسیم
در تصویر زیر Lock‌های ایجاد شده در 3 حالت رو مشاهده میکنین که هیچ تفاوتی با هم ندارن (از DMV سیستمی sys.dm_tran_locks کمک گرفتیم تا لیست Lock‌های در حال اجرا رو مشاهده کنیم)


7- چه زمانی استفاده از HOLDLOCK در کنار UPDLOCK مفید هست؟
زمانی که به Range-Key Lock نیاز داریم و میخوایم بر روی بازه (محدوده) رکورد‌های SELECT شده قفل بگذاریم (مانند Serializable) و نه صرفا خود رکورد‌های SELECT شده (مانند Repeatable Read)
در واقع شرط WHERE مون بر روی Index و توسط عملگر مساوی هایی که مستقیما مقدار رو چک میکنین (مانند عملگر = یا IN) نیست  
و چون این نکته ای ظریف و نیازمند دقت هست برنامه نویسان ترجیح میدن جهت محکم کاری بیشتر از HOLDLOCK در کنار UPDLOCK استفاده کنند و همین دلیل رایج بودنش هست
مطالب
تبدیل اعداد صحیح و اعشاری به حروف در T-SQL با استفاده از Join
استفاده شده از SQL 2008 

روش کار :

1-  دریافت پارامتر ورودی به صورت رشته
2-  درج عناوین اعداد، ارزش مکانی اعداد صحیح و اعشاری  هرکدام در یک جدول
3-  جدا کردن ارقام صحیح و اعشاری
4-  جداکردن سه رقم سه رقم اعداد صحیح و انتقال آنها به جدول مربوطه
5-  Join  جداول عناوین و ارقام جدا شده
6-  ارسال ارقام اعشاری به همین تابع
7-  مشخص کردن ارزش مکانی رقم اعشار
8-  اتصال رشته حروف صحیح و اعشاری

در آخر این مطلب کد این تابع را به صورت کامل، برای دانلود قرار داده ام.

بررسی قسمت‌های مختلف کد


برای اینکه محدودیتی در تعداد ارقام صحیح و اعشاری نداشته باشیم، پارامتر ورودی را از نوع VARCHAR می‌گیریم. پس باید ورودی را بررسی کنیم تا رشته عددی باشد.

بررسی رشته ورودی:

-- @pNumber   پارامتر ورودی

IF LEN(ISNULL(@pNumber, '')) = 0  RETURN NULL

IF (PATINDEX('%[^0-9.-]%', @pNumber) > 0)
   OR (LEN(@pNumber) -LEN(REPLACE(@pNumber, '-', '')) > 1)
   OR (LEN(@pNumber) -LEN(REPLACE(@pNumber, '.', '')) > 1)
   OR (CHARINDEX('-', @pNumber) > 1)
RETURN 'خطا'

IF PATINDEX('%[^0]%', @pNumber) = 0  RETURN 'صفر'
IF (CHARINDEX('.', @pNumber) = 1) SET @pNumber='0'+@pNumber

DECLARE @Negative AS VARCHAR(5) = '';
IF LEFT(@pNumber, 1) = '-'
BEGIN
    SET @pNumber = SUBSTRING(@pNumber, 2, 100)
    SET @Negative = 'منفی '
END
- بررسی NULL  ، خالی بودن و یا داشتن فاصله در رشته،  با دانستن اینکه تابع LEN  فاصله‌های آخر یک رشته را درنظر نمی‌گیرد.
- بررسی رشته ورودی برای پیدا کردن کاراکتر غیر عددی، نقطه و منفی. بررسی تعداد علامت منفی و نقطه که بیشتر از یک مورد نباشند، و در نهایت بررسی اینکه علامت منفی در ابتدای رشته ورودی باشد.
- بررسی صفر بودن ورودی(0)، مقدار ورودی شروع شونده با ممیز(0213. ) و مقدار عددی منفی(21210.0021-).
چیز دیگری به ذهنم نرسید!

درج عناوین در جداول مربوطه:

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

DECLARE @NumberTitle TABLE (val  INT,Title NVARCHAR(100));
INSERT INTO @NumberTitle (val,Title)
VALUES(0, ''),(1, 'یک') ,(2, 'دو'),(3, 'سه'),(4, 'چهار')
,(5, 'پنج'),(6, 'شش'),(7, 'هفت'),(8, 'هشت')
,(9, 'نه'),(10, 'ده'),(11, 'یازده'),(12, 'دوازده')
,(13, 'سیزده'),(14, 'چهارده'),(15, 'پانزده'),(16, 'شانزده')
,(17, 'هفده'),(18, 'هجده'),(19, 'نوزده'),(20, 'بیست')
,(30, 'سی'),(40, 'چهل'),(50, 'پنجاه'),(60, 'شصت')
,(70, 'هفتاد'),(80, 'هشتاد'),(90, 'نود'),(100, 'صد')
,(200, 'دویست'),(300, 'سیصد'),(400, 'چهارصد'),(500, 'پانصد')
,(600, 'ششصد'),(700, 'هفتصد'),(800, 'هشتصد'),(900, 'نهصد')

DECLARE @PositionTitle TABLE (id  INT,Title NVARCHAR(100));
INSERT INTO @PositionTitle (id,title)
VALUES (1, ''),(2, 'هزار'),(3, 'میلیون'),(4, 'میلیارد'),(5, 'تریلیون')
,(6, 'کوادریلیون'),(7, 'کوینتیلیون'),(8, 'سیکستیلون'),(9, 'سپتیلیون')
,(10, 'اکتیلیون'),(11, 'نونیلیون'),(12, 'دسیلیون')
,(13, 'آندسیلیون'),(14, 'دودسیلیون'),(15, 'تریدسیلیون')
,(16, 'کواتردسیلیون'),(17, 'کویندسیلیون'),(18, 'سیکسدسیلیون')
,(19, 'سپتندسیلیون'),(20, 'اکتودسیلیوم'),(21, 'نومدسیلیون')

DECLARE @DecimalTitle TABLE (id  INT,Title NVARCHAR(100));
INSERT INTO @DecimalTitle (id,Title)
VALUES( 1 ,'دهم' ),(2 , 'صدم'),(3 , 'هزارم')
,(4 , 'ده-هزارم'),(5 , 'صد-هزارم'),(6 , 'میلیون ام')
,(7 , 'ده-میلیون ام'),(8 , 'صد-میلیون ام'),(9 , 'میلیاردم')
,(10 , 'ده-میلیاردم')


جداسازی رقم صحیح و اعشاری:

عدد ورودی ممکن است حالت‌های مختلفی داشته باشد مثل:         .00002 , 0.000000 , 234.434400000000 , 123.
بنابراین براساس ممیز، قسمت صحیح را از اعشاری جدا می‌کنیم. برای ورودی که با ممیز شروع شود، در ابتدا تابع بررسی می‌کنیم و عدد صفر را به رشته اضافه می‌کنیم.

بعد از ممیز و اعداد بزرگتر از یک، با صفرهای بی ارزش چه کنیم؟ شاید اولین چیزی که به ذهن برسد استفاده از حلقه (WHILE) برای حذف صفرهای بی ارزش قسمت ممیز باشد؛ ولی من ترجیح می‌دهم که از روش دیگری استفاده کنم :

برعکس کردن رشته قسمت اعشاری، پیدا کردن مکان اولین عدد غیر صفر منهای یک ، و کم کردن عدد بدست آمده از طول رشته اعشاری، قسمت مورد نظر ما را برخواهد گرداند:
SUBSTRING(@DecimalNumber,1, len(@DecimalNumber )-PATINDEX('%[^0]%', REVERSE (@DecimalNumber))-1)
 اما اگر عدد ورودی 20.0 باشد همچنان صفر بی ارزش بعداز ممیز را خواهیم داشت. برای رفع این مشکل کافی است که کاراکتری غیر از صفر را به اول رشته اعشاری اضافه کنیم. من از علامت '?' استفاده کردم. پس به علت اضافه کردن کاراکتر، استارت را از 2 شروع کرده و دیگر نیازی به -1 نخواهیم داشت. با کد زیر قسمت صحیح و اعشاری را بدست می‌آوریم:
DECLARE @IntegerNumber NVARCHAR(100),
@DecimalNumber NVARCHAR(100),
@PointPosition INT =case CHARINDEX('.', @pNumber) WHEN 0 THEN LEN(@pNumber)+1 ELSE CHARINDEX('.', @pNumber) END

SET @IntegerNumber= LEFT(@pNumber, @PointPosition - 1)
SET @DecimalNumber= '?' + SUBSTRING(@pNumber, @PointPosition + 1, LEN(@pNumber))
SET @DecimalNumber=  SUBSTRING(@DecimalNumber,2, len(@DecimalNumber )-PATINDEX('%[^0]%', REVERSE (@DecimalNumber)))

SET @pNumber= @IntegerNumber


جداد کردن سه رقم سه رقم :

- بدست آوردن یکان، دهگان و صدگان
- برای قسمت دهگان، اگر عددی بین 10 تا 19 باشد به صورت کامل (مثلا 15) و در غیر این صورت فقط رقم دهگان. برای بدست آوردن یکان اگر دو رقم آخر بین 10 و 19 بود صفر و در غیر این صورت یکان برگردانده می‌شود و در جدول MyNumbers درج می‌گردد. 
DECLARE @Number AS INT
DECLARE @MyNumbers TABLE (id INT IDENTITY(1, 1), Val1 INT, Val2 INT, Val3 INT)

WHILE (@pNumber) <> '0'
BEGIN
    SET @number = CAST(SUBSTRING(@pNumber, LEN(@pNumber) -2, 3)AS INT)
    
INSERT INTO @MyNumbers
SELECT (@Number % 1000) -(@Number % 100),
CASE 
WHEN @Number % 100 BETWEEN 10 AND 19 THEN @Number % 100
ELSE (@Number % 100) -(@Number % 10)
END,
CASE 
WHEN @Number % 100 BETWEEN 10 AND 19 THEN 0
ELSE @Number % 10
END
    
    IF LEN(@pNumber) > 2
        SET @pNumber = LEFT(@pNumber, LEN(@pNumber) -3)
    ELSE
        SET @pNumber = '0'
END

سطری که تمام مقادیر آن صفر باشد برای ما بی ارزش محسوب می‌شود، مانند سطر یک در عکس زیر (جدول MyNumbers) برای عدد 1200955000 :
@MyNumbers

استفاده از JOIN :

JOIN  کردن جدول اعداد با عناوین عددی براساس ارزش آن‌ها و JOIN  جدول اعداد با جدول ارزش مکانی براساس ID به صورت نزولی(شماره سطر).
DECLARE @Str AS NVARCHAR(2000) = '';
SELECT @Str += REPLACE(REPLACE(LTRIM(RTRIM(nt1.Title + ' ' + nt2.Title + ' ' + nt3.title)),'  ',' '),' ', ' و ')
       + ' ' + pt.title + ' و '
FROM   @MyNumbers  AS mn
       INNER JOIN @PositionTitle pt
            ON  pt.id = mn.id
       INNER JOIN @NumberTitle nt1
            ON  nt1.val = mn.Val1
       INNER JOIN @NumberTitle nt2
            ON  nt2.val = mn.Val2
       INNER JOIN @NumberTitle nt3
            ON  nt3.val = mn.Val3
WHERE  (nt1.val + nt2.val + nt3.val > 0)
ORDER BY pt.id DESC
Replace داخلی: جایگزین کردن "دو فاصله‌ی خالی" با "یک فاصله‌ی خالی"
Replace بیرونی: جایگزینی فاصله‌های خالی با ' و '
همانطور که در بالا اشاره کردم سطرهایی که val2,val1 و val3 آن صفر باشد برای ما بی ارزش هستند، پس آنها را با شرط نوشته شده حذف می‌کنیم.


بدست آوردن مقدار اعشاری:

خوب! حالا نوبت به عدد اعشاری می‌رسد. برای بدست آوردن حروف، مقدار اعشاری بدست آمده را به همین تابع ارسال می‌کنیم و برای بدست آوردن عنوان ارزش مکانی، براساس طول اعشار (ID) آن را در جدول مربوطه پیدا می‌کنیم.
اگر عدد ورودی مثلا 0.355 باشد، تابع باید صفر اول را شناسایی و قسمت عناوین اعشاری را به آن اضافه کند، که این کار با شرط ذیل انجام می‌شود.
اگر رشته اعشار بدون مقدار باشد، تابع مقدار NULL بر می‌گرداند (قسمت بررسی رشته ورودی) و هر رشته ای که با NULL جمع شود برابر با NULL خواهد بود. در این صورت با توجه به کد زیر مقداری به رشته Str به عنوان قسمت اعشاری، اضافه نمی‌گردد.
IF @IntegerNumber='0'  
SET @Str=CASE WHEN PATINDEX('%[^0]%', @DecimalNumber) > 0 THEN @Negative ELSE '' END + 'صفر'
ELSE
SET @Str = @Negative  + LEFT (@Str, LEN(@Str) -2)

DECLARE @PTitle NVARCHAR(100)=ISNULL((SELECT Title FROM @DecimalTitle WHERE id=LEN(@DecimalNumber)),'')
SET @Str += ISNULL(' ممیز '+[dbo].[fnNumberToWord_Persian](@DecimalNumber) +' '+@PTitle,'')
RETURN @str

مثال: رشته '5445789240.54678000000000'

پنج میلیارد و چهارصد و چهل و پنج میلیون و هفتصد و هشتاد و نه هزار و دویست و چهل  ممیز پنجاه و چهار هزار و ششصد و هفتاد و هشت  صد-هزارم  

دانلود فایل



نظرات مطالب
LINQ to Sharepoint Class
لطفا اگه امکان داره در مورد join لیستهای شیرپوینت با LINQ توضیح بدید.