روش TPH
در این روش، ارث بری از طریق فقط یک جدول ایجاد میشود و زیر مجموعهها بر اساس مقدار یک فیلد از یکدیگر متمایز میشوند. پس اگر جدولی دارید که برای متمایز کردن رکوردهای آن از یک فیلد استفاده میکنید، روش TPH مناسب شما است. با روش TPH نیز میتوانید به همان مدلی که در روش TPT دارید برسید، تنها تفاوت این هست که در روش TPH، تمامی دادهها در یک جدول قرار دارند و یک فیلد برای متمایز کردن رکوردها استفاده میشود. همه چیز با مثال عملی واضحتر است. پس کار خود را با یک مثال ادامه میدهیم. جدول مثال ما در شکل زیر مشخص است.
به نظر میرسد که این جدول با جداول قسمت قبل شباهتی دارد. بله! فیلدهای جداول مثال قبل در این جدول آمده اند.
- فیلدهای FirstName و LastName از جدول Persons
- فیلد HireDate از جدول Instructors
- فیلد EnrollmentDate، Credits و Degree از جدول Students
- فیلد AdminDate از جدول Admins
- فیلدهای BusinessCredits و Discipline از جدول BusinessStudents
یک فیلد با نام PersonCategory نیز اضافه شده است که «مقداری عددی» میپذیرد و برای «متمایز کردن رکوردها» استفاده میشود:
- 1 ، نمایانگر Student
- 2 ، نمایانگر Instructor
- 3 ، نمایانگر Admin
- 4 ، نمایانگر BusinessStudent
از این جدول میخواهیم به مدل قسمت اول برسیم اما این بار با استفاده از روش TPH. در شکل زیر، جدول Persons به صورت مدل شده در برنامه نشان داده شده است.
حال باید خصیصههای موجودیت Person را به موجودیتهای مشتق شده منتقل کرد. بدین منظور، هر خصیصه از موجودیت Person را انتخاب، کلیدهای Ctrl+X را فشار دهید، سپس بر روی قسمت Properties موجودیت مشتق شدهی مورد نظر رفته و کلیدهای Ctrl+V را فشار دهید. نتیجه در شکل زیر نشان داده شده است.
اکنون زمان آن رسیده است تا جدول متناظر با هر یک از موجودیتهای مشتق شده را معرفی کنیم. تمامی موجودیتهای مشتق شده از جدول Persons استفاده میکنند. بر روی هر یک از آنها کلیک راست کرده و گزینهی Table Mapping را انتخاب کنید. پنجره ی Mapping Details نشان داده میشود. ابتدا بر روی عبارت Add a Table or View و سپس بر روی نشانگر رو به پایینی که کنار آن ظاهر میشود کلیک کنید (شکل زیر).
آیتم Persons را انتخاب کنید. اکنون باید فیلد تفکیک کنندهی رکوردها را مشخص کنیم. برای این حالت باید یک شرط ایجاد نمود. در همان پنجرهی Mapping Details، عبارتی با عنوان Add a Condition وجود دارد. بر روی آن کلیک و در لیستی که ظاهر میشود، آیتم PersonCategory را انتخاب کنید (شکل زیر).
سپس در ستون Value/Property، مقدار آن را "1" قرار دهید (شکل زیر).
تناظر میان موجودیت و جدول Persons و مقداردهی مناسب به فیلد متمایز کننده را برای تمامی موجودیتهای مشتق شده انجام دهید. دلیل این کار این است که EF بداند هر رکورد در چه زمانی باید به چه موجودیتی تبدیل شود. دقت کنید که پیشتر به مقدار فیلد متمایز کننده برای هر موجودیت اشاره کردیم. نکتهی مهم اینکه یک شرط نیز باید برای موجودیت Person ایجاد و مقدار فیلد متمایز کنندهی آن را "صفر" تعریف کنید.
مثال ما آماده است. آن را امتحان میکنیم.
using (PersonDbEntities context = new PersonDbEntities()) { var people = from p in context.Persons select p; foreach (Person person in people) { Console.WriteLine("{0}, {1}", person.LastName, person.FirstName); if (person is Student) Console.WriteLine(" Degree: {0}", ((Student)person).Degree); if (person is BusinessStudent) Console.WriteLine(" Discipline: {0}", ((BusinessStudent)person).Discipline); } Console.ReadLine(); }
مزایای روش TPH
- سرعت بالای عملیات CRUD، به دلیل وجود تمامی دادهها در یک جدول
- تعداد جداول در پایگاه داده، کم و مدیریت آنها آسانتر است
معایب روش TPH
- افزونگی داده ها. مقادیر برخی ستونها برای بعضی از رکوردها، حاوی مقدار NULL است و تعداد این ستونها به تعداد زیر مجموعهها ارتباط دارد
- عیب اول، باعث میشود تا در صورتی که دادهها به صورت دستی تغییر پیدا کنند، جامعیت دادهها از بین برود
- افزایش بی دلیل حجم داده ها
- اضافه و حذف کردن موجودیتها به مدل، عملی زمانبر و پیچیده است
تنظیمات روابط یک به چند در EF Core
همان اسکریپت ابتدای مطلب «شروع به کار با EF Core 1.0 - قسمت 4 - کار با بانکهای اطلاعاتی از پیش موجود» را درنظر بگیرید. رابطهی تعریف شدهی در آن از نوع one-to-many است: یک بلاگ که میتواند چندین مطلب را داشته باشد.
اگر EF Core را وادار به تولید نگاشتهای Code First معادل آن کنیم، به این خروجیها خواهیم رسید:
الف) با استفاده از روش Fluent API
دستور استفاده شده برای مهندسی معکوس بانک اطلاعاتی نمونه:
dotnet ef dbcontext scaffold "Data Source=(local);Initial Catalog=BloggingCore2016;Integrated Security = true" Microsoft.EntityFrameworkCore.SqlServer -o Entities --context MyDBDataContext --verbose
using System; using System.Collections.Generic; namespace Core1RtmEmptyTest.Entities { public partial class Blog { public Blog() { Post = new HashSet<Post>(); } public int BlogId { get; set; } public string Url { get; set; } public virtual ICollection<Post> Post { get; set; } } }
using System; using System.Collections.Generic; namespace Core1RtmEmptyTest.Entities { public partial class Post { public int PostId { get; set; } public string Content { get; set; } public string Title { get; set; } public virtual Blog Blog { get; set; } public int BlogId { get; set; } } }
using System; using Microsoft.EntityFrameworkCore; using Microsoft.EntityFrameworkCore.Metadata; namespace Core1RtmEmptyTest.Entities { public partial class MyDBDataContext : DbContext { protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { optionsBuilder.UseSqlServer(@"Data Source=(local);Initial Catalog=BloggingCore2016;Integrated Security = true"); } protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity<Blog>(entity => { entity.Property(e => e.Url).IsRequired(); }); modelBuilder.Entity<Post>(entity => { entity.HasOne(d => d.Blog) .WithMany(p => p.Post) .HasForeignKey(d => d.BlogId); }); } public virtual DbSet<Blog> Blog { get; set; } public virtual DbSet<Post> Post { get; set; } } }
نحوهی تشخیص خودکار روابط
EF Core به صورت پیش فرض، روابط را بر اساس ارجاعات بین کلاسها تشخیص میدهد. در اینجا به خاصیت Blog نام navigation property را میدهند:
public virtual Blog Blog { get; set; }
public virtual ICollection<Post> Post { get; set; }
نحوهی تشخیص خودکار کلیدهای خارجی
اگر در یک طرف رابطهی تشخیص داده شده، خاصیتی با یکی از سه نام زیر وجود داشت:
<primary key property name> <navigation property name><primary key property name> <principal entity name><primary key property name>
برای مثال در رابطهی فوق، نام خاصیت BlogId دقیقا بر اساس همان الگوی <primary key property name> طرف دیگر رابطهاست:
public virtual Blog Blog { get; set; } public int BlogId { get; set; }
تا اینجا اگر مطلب را دنبال کرده باشید به این نتیجه خواهید رسید که دو کلاس فوق، اساسا نیازی به هیچ نوع تنظیم Fluent و یا Data annotations ایی برای برقراری ارتباط یک به چند ندارند. چون روابط بین آنها بر اساس خواص راهبری (navigation property) و همچنین الگوی <primary key property name>، به صورت خودکار قابل تشخیص و تنظیم است. به علاوه ... در هر طرف رابطه، فقط یک navigation property وجود دارد و نیازی به تنظیم دستی سر دیگر رابطه نیست.
استفاده از Fluent API برای تنظیم رابطهی One-to-Many
در تنظیمات فوق، در متد OnModelCreating، ذکر صریح این روابط را صرفا جهت از بین بردن هرگونه ابهامی مشاهده میکنید:
modelBuilder.Entity<Post>(entity => { entity.HasOne(d => d.Blog) .WithMany(p => p.Post) .HasForeignKey(d => d.BlogId); });
مرحلهی بعد، مشخص کردن سر دیگر رابطه (inverse navigation) است. اینکار توسط یکی از متدهای WithOne و یا WithMany انجام میشود.
متدهایی که اسامی فرد دارند مانند HasOne/WithOne به یک navigation property ساده اشاره میکنند.
متدهایی که اسامی جمع دارند مانند HasMany/WithMany به collection navigation properties اشاره خواهند کرد.
متد HasForeignKey نیز برای ذکر صریح کلید خارجی بکار رفتهاست.
ب) با استفاده از روش data-annotations
دستور استفاده شده برای مهندسی معکوس بانک اطلاعاتی نمونه:
dotnet ef dbcontext scaffold "Data Source=(local);Initial Catalog=BloggingCore2016;Integrated Security = true" Microsoft.EntityFrameworkCore.SqlServer -o Entities --context MyDBDataContext --verbose -a
using System; using System.Collections.Generic; using System.ComponentModel.DataAnnotations; using System.ComponentModel.DataAnnotations.Schema; namespace Core1RtmEmptyTest.Entities { public partial class Blog { public Blog() { Post = new HashSet<Post>(); } public int BlogId { get; set; } [Required] public string Url { get; set; } [InverseProperty("Blog")] public virtual ICollection<Post> Post { get; set; } } }
using System; using System.Collections.Generic; using System.ComponentModel.DataAnnotations; using System.ComponentModel.DataAnnotations.Schema; namespace Core1RtmEmptyTest.Entities { public partial class Post { public int PostId { get; set; } public string Content { get; set; } public string Title { get; set; } [ForeignKey("BlogId")] [InverseProperty("Post")] public virtual Blog Blog { get; set; } public int BlogId { get; set; } } }
using System; using Microsoft.EntityFrameworkCore; using Microsoft.EntityFrameworkCore.Metadata; namespace Core1RtmEmptyTest.Entities { public partial class MyDBDataContext : DbContext { protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { optionsBuilder.UseSqlServer(@"Data Source=(local);Initial Catalog=BloggingCore2016;Integrated Security = true"); } protected override void OnModelCreating(ModelBuilder modelBuilder) { } public virtual DbSet<Blog> Blog { get; set; } public virtual DbSet<Post> Post { get; set; } } }
[ForeignKey("BlogId")] [InverseProperty("Post")] public virtual Blog Blog { get; set; } public int BlogId { get; set; }
در این حالت (داشتن بیش از یک خاصیت راهبری)، باید ویژگی InverseProperty را نیز به سر دوم رابطه، اعمال کرد.
[InverseProperty("Blog")] public virtual ICollection<Post> Post { get; set; }
مطالب تکمیلی
علت virtual بودن خواص راهبری تولید شده
اگر دقت کنید، EF Core کدی را که تولید کردهاست، به همراه خاصیتهایی virtual است:
public virtual Blog Blog { get; set; }
الف) پیاده سازی lazy loading (بارگذاری خودکار اعضای مرتبط (همان خواص راهبری) با اولین دسترسی به آنها)
ب) پیاده سازی change tracking
مبحث lazy loading فعلا در EF Core 1.0 پشتیبانی نمیشود. اما change tracking آن فعال است.
بنابراین اگر مشاهده کردید خواص راهبری به صورت virtual تعریف شدهاند، علت آن فعال سازی lazy loading است و اگر سایر خواص به صورت virtual تعریف شدهاند، هدف اصلی آن بهبود عملکرد سیستم change tracking است.
همچنین اگر دقت کرده باشید، نوع مجموعهها نیز ICollection ذکر شدهاست. این مورد نیز یکی دیگر از پیش فرضهای توکار EF Core است؛ در جهت تشکیل پروکسیها بر روی خواص راهبری مجموعهای (علاوه بر virtual تعریف کردن آنها). عنوان شدهاست که اگر برای مثال از List استفاده کنید (پیاده سازی اینترفیس) یا هر اینترفیس دیگری که از ICollection مشتق شدهاست، این پروکسیها تشکیل نخواهند شد.
واکشی اعضای به هم مرتبط
همانطور که عنوان شد، نگارش اول EF Core برخلاف EF 6.x از Lazy loading پشتیبانی نمیکند. البته این مساله در کل مورد مثبتی است؛ خصوصا در برنامههای وب! چون استفادهی نادرست از Lazy loading که به select n+1 نیز مشهور است، سبب رفت و برگشتهای بیشماری به بانک اطلاعاتی میشود و عموم برنامه نویسهای وب باید مدام توسط برنامههای Profiler بررسی کنند که آیا این مساله رخ دادهاست یا خیر. فعلا EF Core از این مشکل در امان است!
اما ... اگر به روش کار EF 6.x عادت کرده باشید، قطعه کد ذیل:
var firstPost = context.Post.First(); Console.WriteLine(firstPost.Blog.Url);
System.NullReferenceException Object reference not set to an instance of an object.
برای رفع این مشکل باید توسط متد Include، سبب لغو عملیات Lazy loading و واکشی صریح Blog مرتبط شویم که اصطلاحا به آن eager loading میگویند:
var firstPost = context.Post.Include(x => x.Blog).First(); Console.WriteLine(firstPost.Blog.Url);
نکتهای در مورد سطوح بارگذاری اعضای به هم مرتبط در EF Core
متد Include ایی را که تا اینجا مشاهده کردید، با EF 6.x تفاوتی ندارد. برای مثال اگر شیء Blog حاوی خواص راهبری Posts و همچنین Owner باشد، برای بارگذاری این اعضای مرتبط، میتوان همانند قبل، متدهای Include را پشت سر هم ذکر کرد:
var blogs = context.Blogs .Include(blog => blog.Posts) .Include(blog => blog.Owner) .ToList();
var blogs = context.Blogs .Include(blog => blog.Posts) .ThenInclude(post => post.Author) .ToList();
همچنین در اینجا امکان ذکر زنجیروار متدهای ThenInclude هم هست:
var blogs = context.Blogs .Include(blog => blog.Posts) .ThenInclude(post => post.Author) .ThenInclude(author => author.Photo) .ToList();
به علاوه امکان ذکر چندین ریشه و چندین زیر ریشه هم وجود دارند:
var blogs = context.Blogs .Include(blog => blog.Posts) .ThenInclude(post => post.Author) .ThenInclude(author => author.Photo) .Include(blog => blog.Owner) .ThenInclude(owner => owner.Photo) .ToList();
یک نکته: متد Include تنها زمانی درنظر گرفته خواهد شد که نوع خروجی نهایی کوئری، دقیقا از نوع موجودیتی باشد که با آن شروع به کار کردهایم. برای مثال اگر در این بین یک Select اضافه شود و فقط تنها تعدادی از خواص Blog واکشی شوند، از تمام Includeهای ذکر شده صرفنظر میشود؛ مانند کوئری ذیل:
var blogs = context.Blogs .Include(blog => blog.Posts) .Select(blog => new { Id = blog.BlogId, Url = blog.Url }) .ToList();
تنظیمات حذف آبشاری در رابطهی one-to-many
زمانیکه در رابطهی one-to-many قسمت principal (والد رابطه) و یا همان Blog در مثال جاری حذف میشود، سه اتفاق برای فرزندان آن میسر خواهند بود:
الف) Cascade : در این حالت ردیفهای فرزندان وابسته نیز حذف خواهند شد.
باید دقت داشت که حالت Cascade فقط برای موجودیتهایی اعمال میشود که توسط Context بارگذاری شده و در آن وجود دارند. اگر میخواهید سایر موجودیتهای مرتبط نیز با این روش حذف شوند، باید در سمت دیتابیس نیز تنظیماتی مانند ON DELETE CASCADE زیر نیز وجود داشته باشند:
CONSTRAINT [FK_Post_Blog_BlogId] FOREIGN KEY ([BlogId]) REFERENCES [Blog] ([BlogId]) ON DELETE CASCADE
modelBuilder.Entity<Post>() .HasOne(p => p.Blog) .WithMany(b => b.Posts) .OnDelete(DeleteBehavior.Cascade);
ج) Restrict: هیچ تغییری بر روی فرزندان رابطه رخ نمیدهد.
یک نکته: به صورت پیش فرض اگر رابطهی one-to-many، به Required تنظیم شود، حالت حذف آن cascade خواهد بود. در غیراینصورت برای حالتهای Optional، حالت SetNull تنظیم میگردد:
modelBuilder.Entity<Post>() .HasOne(p => p.Blog) .WithMany(b => b.Posts) .IsRequired();
به علاوه باید دقت داشت، همان مباحث «تعیین اجباری بودن یا نبودن ستونها در EF Core» در قسمت قبل، در اینجا هم صادق است. برای مثال چون BlogId (کلید خارجی در کلاس Post) از نوع int است و نال پذیر نیست، بنابراین از دیدگاه EF Core یک فیلد اجباری درنظر گرفته میشود. به همین جهت است که در کدهای تولید شدهی توسط EF Core در ابتدای بحث، ذکر متد IsRequired و یا OnDelete را مشاهده نمیکنید.
بنابراین اگر میخواهید حالت SetNull را فعال کنید، باید این کلید خارجی را نیز نال پذیر و به صورت int? BlogId ذکر کنید تا optional درنظر گرفته شود.
EF Code First #7
- جزئیات بیشتر از زبان طراحان EF:
Deleting orphans with Entity Framework
+ طراحی پیش فرض است؛ مطابق مستندات MSDN:
If a foreign key on the dependent entity is nullable, Code First does not set cascade delete on the relationship, and when the principal is deleted the foreign key will be set to null.
SQL Server
SQL Server 2005
SQL Server 2008
- SQL Server 2008: Script Data
- سرویس پک یک SQL Server 2008
- اس کیوال سرور 2008 و عملگرهای C مانند
- انتقال فایلهای دیتابیس اس کیوال سرور 2008
- فشرده سازی اطلاعات در SQL server 2008
- مقایسه امنیت Oracle11g و SQL server 2008 از دید آمار در سال 2009
- آشنایی با قابلیت FileStream اس کیوال سرور 2008 - قسمت اول
- آشنایی با قابلیت FileStream اس کیوال سرور 2008 - قسمت دوم
- آشنایی با قابلیت FileStream اس کیوال سرور 2008 - قسمت سوم
- تهیه گزارش از منسوخ شدههای مورد استفاده در SQL Server 2008
- استفاده از قابلیت Script Data اس کیوال سرور 2008 از طریق برنامه نویسی
- Resource Governor در 2008 SQL Server
- Embed کردن SQL Server Express 2008 در یک برنامه
SQL Server 2012
- Microsoft® SQL Server® 2012
- نحوه تبدیل نگارش SQL Server 2012 RTM مدت دار، به نگارش کامل
- نحوه ایجاد Sequence و استفاده آن در Sql Server 2012
- بررسی الگوهای ایندکسهای Non-Clustered در SQL Server
- آشنایی با Column Store Index در SQL Server 2012
- آشنایی با Contained Databases در SQL Server 2012
- استفاده از Sparse Columns در SQL Server 2012
- تغییر نام پایگاه داده و فایل هایش در SQL Server 2012
- گرفتن خروجی XML از جداول در SQL Server 2012
- گرفتن خروجی JSON از جداول در SQL Server 2012
- آشنایی با FileTable در SQL Server 2012 بخش 1
- آشنایی با FileTable در SQL Server 2012 بخش 2
SQL Serve 2014
- معرفی OLTP درون حافظهای در SQL Server 2014
- ایجاد جداول بهینه سازی شده برای حافظه در SQL Server 2014
- ابزارهای مهاجرت به OLTP درون حافظهای در SQL Server 2014
- ماندگاری با تاخیر در SQL Server 2014
- امکان استفاده از یک هارد SSD بجای RAM در SQL Server 2014
- کاهش حجم لاگ فایلهای اسکیوال سرور 2005 و 2008
- گزارشگیری از تاریخچهی پشتیبانگیریها در اس کیوال سرور
- گزارشگیری از تاریخچهی اجرای کوئریها در SQL Server
- تشخیص کمبود ایندکسها در SQL server
- پیدا کردن لیست SQL serverهای نصب شده در یک شبکه
- چرا نباید از کوئریهای select * استفاده کرد؟
- منسوخ شدهها در نگارشهای جدید SQL server
- پیدا کردن وابستگیهای اشیاء در SQL Server
- به روز رسانی Viewها و رویههای ذخیره شده در SQL server
- نحوه راه اندازی مجدد یک دیتابیس اس کیوال سرور پس از پر شدن هارد دیسک
- مشکل اتصال به اس کیوال سرور 2000 از طریق management studio 2008
- مشکل ی و ک فارسی و عربی در یک دیتابیس اس کیوال سرور
- مونیتور کردن میزان مصرف CPU در اس کیوال سرور
- تنظیمات پیشنهادی حداکثر حافظهی مصرفی اس کیوال سرور
- Microsoft SQL Server 2008 Management Objects
- مونیتور کردن میزان فضای خالی باقیمانده در سرور توسط اس کیوال سرور
- آیا از وضعیت رویههای ذخیره شدهی دیتابیسهای اس کیوال سرور خود خبر دارید؟
- تعیین اعتبار کردن یک عبارت SQL
- تعیین اعتبار کردن یک عبارت SQL - قسمت دوم
- نگهداری ایندکسها در اسکیوال سرور
- حذف سریع تمام رکوردها در SQL server
- بررسی صحت پشتیبانهای تهیه شده در SQL Server
- یافتن لیست اسمبلیهای ارجاعی
- مقایسه ساختاری دو دیتابیس SQL Server
- sp_send_dbmail و ارسال ایمیل فارسی
- محدود کردن دسترسی به اس کیوال سرور بر اساس IP
- مقایسه نتایج الگوریتمهای هش کردن اطلاعات در اس کیوال سرور و دات نت
- تنظیم درجه سازگاری یک دیتابیس اس کیوال سرور
- مقایسه رکوردهای دو جدول
- تهیه بک آپهای خودکار از SQL Server Express
- بازسازی msdb تخریب شده
- مقایسه حساس به حروف کوچک و بزرگ در SQL Server
- مزیتهای استفاده از رویههای ذخیره شده؛ واقعیت یا توهم؟!
- روشهایی برای حذف رکوردهای تکراری
- ذخیره سازی فایلها در دیتابیس یا استفاده از فایل سیستم متداول؟
- به روز رسانی فیلدهای XML در SQL Server
- Optimize for unknown
- FxCop برای SQL Server
- با رویههای ذخیره شده خود، وب سرویس ایجاد کنید
- به روز رسانی فیلدهای XML در SQL Server - قسمت دوم
- مرجعی در مورد نگارشهای مختلف SQL Server
- یافتن تداخلات Collations در SQL Server
- عدم کاهش حجم لاگ فایل SQL Server
- دریافت خطای database is not accessible و نحوهی رفع مشکل
- سرورهای متصل شدهی SQL Server و مبحث تراکنشها
- چک لیست نصب SQL Server
- درک نمودار
- بررسی مقدار دهی اولیه متغیرها در T-SQL
- اگر نصب سرویس پک اس کیوال سرور Fail شد ...
- ایجاد بک آپ برای دیتابیس با استفاده از CMD
- انتخاب Sub Query درون پرانتزها به کمک [+Ctrl+Shift
- روشی جهت یافتن فیلدهای استفاده شده درون Stored Procedure ، Function و View
- آشنایی با Row_Number،Rank،Dense_Rank،NTILE
- بازگردانی پایگاه داده بدون فایل لاگ
- LocalDB چیست؟
- آشنایی با تابع PATINDEX در SQL Server
- اجرای Stored Procedure با چند نوع مقدار برگشتی توسط EF CodeFirst
- آشنایی با SQL Server Data Tools
- مشکل ارتباط با SQL Server در لوکال
- آشنایی با Window Functionها در SQL Server بخش اول
- آشنایی با Window Functionها در SQL Server بخش دوم
- آشنایی با Window Functionها در SQL Server بخش سوم
- آشنایی با Window Functionها در SQL Server بخش چهارم
- استفاده از SQLDom برای آنالیز عبارات T-SQL
- دسته بندی سطرهای جدول
- حذف نمودن کاراکترهای ناخواسته توسط Recursive CTE قسمت اول
- جستجوی کاراکترهای wildcards توسط ماده اختیاری ESCAPE
- ستون محاسباتی (computed column)
- گذری بر مفاهیم relationship
- حذف کاراکترهای ناخواسته توسط Recursive CTE قسمت دوم
- از کار افتادن SQL Server Agent
- بدست آوردن برگهای یک درخت توسط Recursive CTE
- بررسی مساله متداول Top N در نسخههای مختلف SQL Server
- فعال و غیر فعال کردن قیود
- مروری بر طراحی Schema less بانک اطلاعاتی SisoDb
- اجرای یک Script حاوی دستورات Go در سی شارپ
- آشنایی با Window Functionها در SQL Server بخش پنجم
- افزودن یک DataType جدید برای نگهداری تاریخ خورشیدی - 1
- افزودن یک DataType جدید برای نگهداری تاریخ خورشیدی - 2
- افزودن یک DataType جدید برای نگهداری تاریخ خورشیدی - 3
- نحوه انتقال اطلاعات استخراج شده از وب سرویس به SQL Server به کمک SSIS
- Full Text Search و Rank فیلدهای بازیابی شده
- بررسی دستور Truncate Table و Delete
- Identity و مباحث مربوط به آن (قسمت اول) - آشنایی با Identity
- Identity و مباحث مربوطه (قسمت دوم) نحوه بدست آوردن مقادیر Identity
- ویدئوی آموزش مقدمات CodeFirst در قالب یک کلاس آموزشی به همراه مثال
- مفهوم READ_COMMITTED_SNAPSHOT در EF 6
- آشنایی با SQL Server Common Table Expressions - CTE
- NoSQL و مایکروسافت
- نحوه تهیه گزارش در SSRS و انتشار آن روی وب سرور
- مدیریت اطلاعات وابسته به زمان در بانکهای اطلاعاتی رابطهای
- تبدیل اعداد صحیح و اعشاری به حروف در T-SQL با استفاده از Join
- SQL Instance
- خواندن سریع اطلاعات فایل اکسل و ذخیره در بانک SQL
- افزودن اکانت مدیریتی فراموش شده به SQL Server
- اندازه گیری کارآیی پرس و جوها با استفاده از SET STATISTICS TIME
- ساخت کاربر ویندوز توسط SQL Server
- بررسی Transactions و Locks در SQL Server
- معرفی و استفاده از DDL Triggers در SQL Server
- بررسی دو نکته (ترفند) کاربردی در SQL Server
- بررسی ابزار SQL Server Profiler
- اجرای SSIS Package از طریق برنامه کاربردی
- پردازش دادههای جغرافیایی به کمک SQL Server و Entity framework
- استفاده از قابلیت پارتیشن بندی در آرشیو جداول بانکهای اطلاعاتی SQL Server
- بررسی بارگذاری دادهها در انبارهای داده و معرفی الگوهای بکار رفته در آن
- بهبود عملکرد SQL Server Locks در سیستمهای با تعداد تراکنش بالا در Entity Framework
- SQL Antipattern #1
- SQL Antipattern #2
- پیاده سازی عملیات صفحه بندی (paging) در sql server
- فعالسازی Multiple Active Result Sets
- استفاده از SQLDom برای آنالیز عبارات T-SQL، قسمت دوم
- اتصال به SQL از راه دور (Remote) و یا به یک سرور در شبکه
- نحوه تعریف Linked Server و دریافت اطلاعات از سروری دیگر