در ردهی بانکهای اطلاعاتی سبک و رایگان، SQL Server CE و همچنین SQLite به صورت توکار (بدون نیاز به کدنویسی خاصی) از رمزنگاری کل بانک اطلاعاتی پشتیبانی میکنند.
روش کار پیش فرض با EF Core همان روش Code First است. ابتدا کلاسها و روابط بین آنها را تنظیم میکنید. سپس با استفاده از ابزارهای Migrations، بانک اطلاعاتی متناظری تولید خواهد شد. این ابزارها به همراه روشی برای مهندسی معکوس ساختار یک بانک اطلاعاتی از پیش موجود، به روش Code First نیز هستند که در ادامه جزئیات آنرا بررسی خواهیم کرد. بنابراین اگر به دنبال روش کاری Database first با EF Core هستید، در اینجا نیز امکان آن وجود دارد.
تهیه یک بانک اطلاعاتی نمونه
برای نمایش امکانات کار با روش Database first، نیاز است یک بانک اطلاعاتی را به صورت مستقل و متداولی ایجاد کنیم. به همین جهت اسکریپت SQL ذیل را توسط Management studio اجرا کنید تا بانک اطلاعاتی BloggingCore2016، به همراه دو جدول به هم وابسته، در آن ایجاد شوند:
پیشنیازهای مهندسی معکوس ساختار بانک اطلاعاتی در EF Core
در قسمت اول در حین بررسی «برپایی تنظیمات اولیهی EF Core 1.0 در یک برنامهی ASP.NET Core 1.0»، چهار مدخل جدید را به فایل project.json برنامه اضافه کردیم. مدخل جدید Microsoft.EntityFrameworkCore.Tools که به قسمت tools آن اضافه شد، پیشنیاز اصلی کار با EF Core Migrations است. همچنین وجود مدخل Microsoft.EntityFrameworkCore.SqlServer.Design برای تدارک امکانات مهندسی معکوس ساختار یک بانک اطلاعاتی SQL Server ضروری است.
تبدیل ساختار دیتابیس BloggingCore2016 به کدهای معادل EF Core آن
پس از فعال سازی ابزارهای خط فرمان EF Core، به پوشهی اصلی پروژه مراجعه کرده، کلید shift را نگه دارید. سپس کلیک راست کرده و گزینهی Open command window here را انتخاب کنید تا خط فرمان از این پوشه آغاز شود. در ادامه دستور ذیل را صادر کنید:
اجرا این دستور سبب اتصال به رشتهی اتصالی ذکر شده که به بانک اطلاعاتی BloggingCore2016 اشاره میکند، میشود. سپس پروایدر مدنظر ذکر شدهاست. سوئیچ o محل درج فایلهای نهایی را مشخص میکند. برای مثال در اینجا فایلهای نهایی مهندسی معکوس شده در پوشهی Entities درج میشوند (تصویر فوق). همچنین در اینجا امکان ذکر فایل context تولیدی نیز وجود دارد. اگر علاقمند باشید تا تمام ریز جزئیات این عملیات را نیز مشاهده کنید، میتوانید پارامتر اختیاری verbose را نیز به انتهای دستور اضافه نمائید.
بقیه مراحل کار با این فایلهای تولید شده، با نکاتی که تاکنون عنوان شدهاند یکی است. برای مثال اگر میخواهید رشتهی اتصالی پیش فرض را از این Context تولید شده خارج کنید:
روش کار دقیقا همانی است که در مطلب «شروع به کار با EF Core 1.0 - قسمت 1 - برپایی تنظیمات اولیه» بررسی شد.
بررسی پارامترهای دیگر ابزار مهندسی معکوس به Code First
اگر دستور dotnet ef dbcontext scaffold --help را صادر کنیم، خروجی راهنمای ذیل را میتوان مشاهده کرد:
نکات تکمیلی مهمی را که از آن میتوان استخراج کرد به این شرح هستند:
- حالت پیش فرض تنظیمات روابط مدلها در این روش، حالت استفاده از Fluent API است. اگر میخواهید آنرا به حالت استفادهی از Data Annotations تغییر دهید، پارامتر a- و یا data-annotations-- را در دستور نهایی ذکر کنید.
- حالت پیش فرض تولید فایلهای نهایی این روش، عدم بازنویسی فایلهای موجود است. اگر میخواهید پس از تغییر بانک اطلاعاتی، مجددا این فایلها را از صفر تولید کنید، پارامتر f- و یا force- را در دستور نهایی ذکر کنید.
بنابراین اگر میخواهید هربار فایلهای نهایی را بازنویسی کنید و همچنین روش کار با Data Annotations را ترجیح میدهید، دستور نهایی، شکل زیر را پیدا خواهد کرد:
کار با یک بانک اطلاعاتی موجود، با روش مهاجرتهای Code First
فرض کنید میخواهید از یک بانک اطلاعاتی از پیش موجود EF 6.x (یا هر بانک اطلاعاتی از پیش موجود دیگری)، به روش پیش فرض EF Core استفاده کنید. برای این منظور:
- ابتدا جدول migration history قدیمی آنرا حذف کنید؛ چون ساختار آن با EF Core یکی نیست.
- سپس با استفاده از دستور dotnet ef dbcontext scaffold فوق، معادل کلاسها، روابط و Context سازگار با EF Core آنرا تولید کنید.
- در ادامه رشتهی اتصالی پیش فرض آنرا از کلاس Context تولیدی خارج کرده و از یکی از روشهای مطرح شدهی در مطلب «شروع به کار با EF Core 1.0 - قسمت 1 - برپایی تنظیمات اولیه» استفاده کنید.
- سپس نیاز است این Context جدید را توسط متد services.AddDbContext به لیست سرویسهای برنامه اضافه کنید. این مورد نیز در قسمت اول بررسی شدهاست.
- مرحلهی بعد، افزودن جدول __EFMigrationsHistory جدید EF Core، به این بانک اطلاعاتی است. برای این منظور به روش متداول فعال کردن مهاجرتها، دستور ذیل را صادر کنید:
تا اینجا کلاس آغازین مهاجرتها تولید میشود. فایل آنرا گشوده و محتوای متدهای Up و Down آنرا خالی کنید:
متدهای up و down را از این جهت خالی میکنیم که علاقمند نیستیم تا ساختاری در بانک اطلاعاتی تشکیل شود و یا تغییر کند (چون این ساختار هم اکنون موجود است).
سپس دستور به روز رسانی بانک اطلاعاتی را صادر کنید:
کار این دستور در اینجا با توجه به خالی بودن متدهای up و down، صرفا ساخت جدول مخصوص __EFMigrationsHistory در بانک اطلاعاتی است؛ بدون تغییری در جداول موجود آن.
پس از این مرحله، روش کار، Code first خواهد بود. برای مثال خاصیتی را به کلاسی اضافه میکنید و سپس دو دستور ذیل را صادر خواهید کرد که در آن v2 یک نام دلخواه است:
تهیه یک بانک اطلاعاتی نمونه
برای نمایش امکانات کار با روش Database first، نیاز است یک بانک اطلاعاتی را به صورت مستقل و متداولی ایجاد کنیم. به همین جهت اسکریپت SQL ذیل را توسط Management studio اجرا کنید تا بانک اطلاعاتی BloggingCore2016، به همراه دو جدول به هم وابسته، در آن ایجاد شوند:
CREATE DATABASE [BloggingCore2016] GO USE [BloggingCore2016] GO CREATE TABLE [Blog] ( [BlogId] int NOT NULL IDENTITY, [Url] nvarchar(max) NOT NULL, CONSTRAINT [PK_Blog] PRIMARY KEY ([BlogId]) ); GO CREATE TABLE [Post] ( [PostId] int NOT NULL IDENTITY, [BlogId] int NOT NULL, [Content] nvarchar(max), [Title] nvarchar(max), CONSTRAINT [PK_Post] PRIMARY KEY ([PostId]), CONSTRAINT [FK_Post_Blog_BlogId] FOREIGN KEY ([BlogId]) REFERENCES [Blog] ([BlogId]) ON DELETE CASCADE ); GO INSERT INTO [Blog] (Url) VALUES ('https://www.dntips.ir/'), ('http://blogs.msdn.com/dotnet'), ('http://blogs.msdn.com/webdev'), ('http://blogs.msdn.com/visualstudio') GO
پیشنیازهای مهندسی معکوس ساختار بانک اطلاعاتی در EF Core
در قسمت اول در حین بررسی «برپایی تنظیمات اولیهی EF Core 1.0 در یک برنامهی ASP.NET Core 1.0»، چهار مدخل جدید را به فایل project.json برنامه اضافه کردیم. مدخل جدید Microsoft.EntityFrameworkCore.Tools که به قسمت tools آن اضافه شد، پیشنیاز اصلی کار با EF Core Migrations است. همچنین وجود مدخل Microsoft.EntityFrameworkCore.SqlServer.Design برای تدارک امکانات مهندسی معکوس ساختار یک بانک اطلاعاتی SQL Server ضروری است.
تبدیل ساختار دیتابیس BloggingCore2016 به کدهای معادل EF Core آن
پس از فعال سازی ابزارهای خط فرمان EF Core، به پوشهی اصلی پروژه مراجعه کرده، کلید shift را نگه دارید. سپس کلیک راست کرده و گزینهی Open command window here را انتخاب کنید تا خط فرمان از این پوشه آغاز شود. در ادامه دستور ذیل را صادر کنید:
dotnet ef dbcontext scaffold "Data Source=(local);Initial Catalog=BloggingCore2016;Integrated Security = true" Microsoft.EntityFrameworkCore.SqlServer -o Entities --context MyDBDataContext --verbose
اجرا این دستور سبب اتصال به رشتهی اتصالی ذکر شده که به بانک اطلاعاتی BloggingCore2016 اشاره میکند، میشود. سپس پروایدر مدنظر ذکر شدهاست. سوئیچ o محل درج فایلهای نهایی را مشخص میکند. برای مثال در اینجا فایلهای نهایی مهندسی معکوس شده در پوشهی Entities درج میشوند (تصویر فوق). همچنین در اینجا امکان ذکر فایل context تولیدی نیز وجود دارد. اگر علاقمند باشید تا تمام ریز جزئیات این عملیات را نیز مشاهده کنید، میتوانید پارامتر اختیاری verbose را نیز به انتهای دستور اضافه نمائید.
بقیه مراحل کار با این فایلهای تولید شده، با نکاتی که تاکنون عنوان شدهاند یکی است. برای مثال اگر میخواهید رشتهی اتصالی پیش فرض را از این Context تولید شده خارج کنید:
public partial class MyDBDataContext : DbContext { protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { optionsBuilder.UseSqlServer(@"Data Source=(local);Initial Catalog=BloggingCore2016;Integrated Security = true"); }
بررسی پارامترهای دیگر ابزار مهندسی معکوس به Code First
اگر دستور dotnet ef dbcontext scaffold --help را صادر کنیم، خروجی راهنمای ذیل را میتوان مشاهده کرد:
Usage: dotnet ef dbcontext scaffold [arguments] [options] Arguments: [connection] The connection string of the database [provider] The provider to use. For example, Microsoft.EntityFrameworkCore.SqlServer Options: -a|--data-annotations Use DataAnnotation attributes to configure the model where possible. If omitted, the output code will use only the fluent API. -c|--context <name> Name of the generated DbContext class. -f|--force Force scaffolding to overwrite existing files. Otherwise, the code will only proceed if no output files would be overwritten. -o|--output-dir <path> Directory of the project where the classes should be output. If omitted, the top-level project directory is used. --schema <schema> Selects a schema for which to generate classes. -t|--table <schema.table> Selects a table for which to generate classes. -e|--environment <environment> The environment to use. If omitted, "Development" is used. -h|--help Show help information -v|--verbose Enable verbose output
- حالت پیش فرض تنظیمات روابط مدلها در این روش، حالت استفاده از Fluent API است. اگر میخواهید آنرا به حالت استفادهی از Data Annotations تغییر دهید، پارامتر a- و یا data-annotations-- را در دستور نهایی ذکر کنید.
- حالت پیش فرض تولید فایلهای نهایی این روش، عدم بازنویسی فایلهای موجود است. اگر میخواهید پس از تغییر بانک اطلاعاتی، مجددا این فایلها را از صفر تولید کنید، پارامتر f- و یا force- را در دستور نهایی ذکر کنید.
بنابراین اگر میخواهید هربار فایلهای نهایی را بازنویسی کنید و همچنین روش کار با Data Annotations را ترجیح میدهید، دستور نهایی، شکل زیر را پیدا خواهد کرد:
dotnet ef dbcontext scaffold "Data Source=(local);Initial Catalog=BloggingCore2016;Integrated Security = true" Microsoft.EntityFrameworkCore.SqlServer -o Entities --context MyDBDataContext --verbose --force --data-annotations
کار با یک بانک اطلاعاتی موجود، با روش مهاجرتهای Code First
فرض کنید میخواهید از یک بانک اطلاعاتی از پیش موجود EF 6.x (یا هر بانک اطلاعاتی از پیش موجود دیگری)، به روش پیش فرض EF Core استفاده کنید. برای این منظور:
- ابتدا جدول migration history قدیمی آنرا حذف کنید؛ چون ساختار آن با EF Core یکی نیست.
- سپس با استفاده از دستور dotnet ef dbcontext scaffold فوق، معادل کلاسها، روابط و Context سازگار با EF Core آنرا تولید کنید.
- در ادامه رشتهی اتصالی پیش فرض آنرا از کلاس Context تولیدی خارج کرده و از یکی از روشهای مطرح شدهی در مطلب «شروع به کار با EF Core 1.0 - قسمت 1 - برپایی تنظیمات اولیه» استفاده کنید.
- سپس نیاز است این Context جدید را توسط متد services.AddDbContext به لیست سرویسهای برنامه اضافه کنید. این مورد نیز در قسمت اول بررسی شدهاست.
- مرحلهی بعد، افزودن جدول __EFMigrationsHistory جدید EF Core، به این بانک اطلاعاتی است. برای این منظور به روش متداول فعال کردن مهاجرتها، دستور ذیل را صادر کنید:
dotnet ef migrations add InitialDatabase
using Microsoft.EntityFrameworkCore.Migrations; namespace Core1RtmEmptyTest.DataLayer.Migrations { public partial class InitialDatabase : Migration { protected override void Up(MigrationBuilder migrationBuilder) { } protected override void Down(MigrationBuilder migrationBuilder) { } } }
سپس دستور به روز رسانی بانک اطلاعاتی را صادر کنید:
dotnet ef database update
پس از این مرحله، روش کار، Code first خواهد بود. برای مثال خاصیتی را به کلاسی اضافه میکنید و سپس دو دستور ذیل را صادر خواهید کرد که در آن v2 یک نام دلخواه است:
dotnet ef migrations add v2 dotnet ef database update
همواره حذف و به روز رسانی تعداد زیادی رکورد توسط EF، بسیار غیربهینه و کند بودهاست؛ از این جهت که یکی از روشهای انجام اینکار، کوئری گرفتن از رکوردهای مدنظر جهت حذف، سپس بارگذاری آنها در حافظه و در آخر حذف یکی یکی آنها بودهاست:
در اینجا در ابتدا، شیءای که قرار است حذف شود، از بانک اطلاعاتی کوئری گرفته میشود تا وارد سیستم Change Tracking شود. سپس از این سیستم ردیابی اطلاعات درون حافظهای، حذف خواهد شد و در نهایت این تغییرات به بانک اطلاعاتی اعمال میشوند. بنابراین در این مثال ساده، حداقل دوبار رفت و برگشت به بانک اطلاعاتی وجود خواهد داشت.
البته راه دومی نیز برای انجام اینکار وجود دارد:
در این مثال، رفت و برگشت ابتدایی، حذف شدهاست و با فرض معلوم بودن کلید اصلی رکورد مدنظر، آنرا وارد سیستم Change Tracking کرده و درنهایت آنرا حذف میکنیم. کار متد Remove در اینجا، علامتگذاری این شیء دارای Id، به صورت EntityState.Deleted است.
اکنون میتوان در EF 7.0، روش سومی را نیز به این لیست اضافه کرد که فقط یکبار رفت و برگشت به بانک اطلاعاتی را سبب میشود:
معرفی متدهای حذف و بهروز رسانی دستهای رکوردها در EF 7.0
EF 7.0 به همراه دو متد جدید ExecuteUpdate و ExecuteDelete (و همچنین نگارشهای async آنها) است که کار بهروز رسانی و یا حذف دستهای رکوردها را بدون دخالت سیستم Change tacking میسر میکنند. مزیت مهم این روش، عدم نیاز به کوئری گرفتن از بانک اطلاعاتی جهت بارگذاری رکوردهای مدنظر در حافظه و سپس حذف یکی یکی آنها است. فقط باید دقت داشت که چون این روش خارج از سیستم Change tracking صورت میگیرد، نتیجهی حاصل، دیگر با اطلاعات درون حافظهای سمت کلاینت، هماهنگ نخواهد بود و کار به روز رسانی دستی آنها بهعهدهی شماست.
بررسی نحوهی عملکرد ExecuteUpdate و ExecuteDelete با یک مثال
فرض کنید مدلهای موجودیتهای برنامه شامل کلاسهای زیر هستند:
که در اینجا یک کاربر میتواند دارای یک آدرس و چندین کتاب تعریف شده باشد؛ با این Context ابتدایی:
مثال 1: حذف دستهای تعدادی کتاب
در اینجا نحوهی استفاده از متد ExecuteDelete را مشاهده میکنید که به انتهای LINQ Query، اضافه شدهاست. در این مثال، تمام کتابهایی که در نامشان حرف 1 وجود دارد، حذف میشوند. این کوئری، به صورت زیر بر روی بانک اطلاعاتی اجرا میشود:
مهمترین مزیت این روش، عدم نیاز به بارگذاری و یا ساخت درون حافظهای لیست کتابهایی است که قرار است حذف شوند. کل این عملیات در یک رفت و برگشت ساده و سریع انجام میشود.
یک نکته: متد ExecuteDelete، تعداد رکوردهای حذف شده را نیز بازگشت میدهد.
مثال 2: حذف کاربران و تمام رکوردهای وابسته به آن
فرض کنید میخواهیم تعدادی از کاربران را از بانک اطلاعاتی حذف کنیم:
اگر این کوئری را با تنظیمات فعلی اجرا کنیم، با خطای زیر متوقف خواهیم شد:
عنوان میکند که یک کاربر، دارای تعدادی کتاب و آدرسی از پیش ثبت شدهاست و نمیتوان آنرا بدون حذف وابستگیهای آن، حذف کرد. اگر کاربری را حذف کنیم، کلیدهای خارجی ذکر شدهی در جداولی که این کلید خارجی را به همراه دارند، غیرمعتبر میشوند (و این کلید خارجی تعریف شده، نال پذیر هم نیست). برای رفع این مشکل، یا باید ابتدا در طی دستوراتی جداگانه، وابستگیهای ممکن را حذف کنیم و یا میتوان تنظیم cascade delete را به نحو زیر به تعریف جداول مرتبط اضافه کرد تا صدور یک دستور delete، به صورت خودکار سبب حذف وابستگیهای مرتبط نیز شود:
همانطور که ملاحظه میکنید، به متد OnModelCreating تنظیم cascade delete وابستگیهای جدول کاربران اضافه شدهاست. پس از این تنظیم، دستور مثال دوم، بدون مشکل اجرا شده و حذف یک کاربر، سبب حذف خودکار کتابها و آدرس او نیز میشود.
مثال 3: بهروز رسانی دستهای از کاربران
فرض کنید میخواهیم LastName تعدادی کاربر مشخص را به مقدار جدید Updated، تغییر دهیم:
برای اینکار، پس از مشخص شدن شرط کوئری در قسمت Where، کار به روز رسانی توسط متد ExecuteUpdate و سپس متد SetProperty صورت میگیرد. در اینجا در ابتدا مشخص میکنیم که کدام خاصیت قرار است به روز رسانی شود و پارامتر دوم آن، مقدار جدید را مشخص میکند. این کوئری به نحو زیر به بانک اطلاعاتی اعمال خواهد شد:
در اینجا میتوان در پارامتر دوم متد SetProperty، از مقدار فعلی سایر خواص نیز استفاده کرد:
که خروجی زیر را تولید میکند:
همچنین میتوان چندین متد SetProperty را نیز به صورت زنجیروار، جهت به روز رسانی چندین خاصیت و فیلد، ذکر کرد:
با این خروجی نهایی:
متد ExecuteUpdate، تعداد رکوردهای بهروز رسانی شده را نیز بازگشت میدهد.
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید: EF7BulkOperations.zip
using var dbContext = new MyDbContext(); var objectToDelete = await dbContext.Objects.FirstAsync(o => o.Id == id); dbContext.Objects.Remove(objectToDelete); await dbContext.SaveChangesAsync();
البته راه دومی نیز برای انجام اینکار وجود دارد:
using var dbContext = new MyDbContext(); var objectToDelete = new MyObject { Id = id }; dbContext.Objects.Remove(objectToDelete); await dbContext.SaveChangesAsync();
اکنون میتوان در EF 7.0، روش سومی را نیز به این لیست اضافه کرد که فقط یکبار رفت و برگشت به بانک اطلاعاتی را سبب میشود:
await dbContext.Objects.Where(x => x.Id == id).ExecuteDeleteAsync();
معرفی متدهای حذف و بهروز رسانی دستهای رکوردها در EF 7.0
EF 7.0 به همراه دو متد جدید ExecuteUpdate و ExecuteDelete (و همچنین نگارشهای async آنها) است که کار بهروز رسانی و یا حذف دستهای رکوردها را بدون دخالت سیستم Change tacking میسر میکنند. مزیت مهم این روش، عدم نیاز به کوئری گرفتن از بانک اطلاعاتی جهت بارگذاری رکوردهای مدنظر در حافظه و سپس حذف یکی یکی آنها است. فقط باید دقت داشت که چون این روش خارج از سیستم Change tracking صورت میگیرد، نتیجهی حاصل، دیگر با اطلاعات درون حافظهای سمت کلاینت، هماهنگ نخواهد بود و کار به روز رسانی دستی آنها بهعهدهی شماست.
بررسی نحوهی عملکرد ExecuteUpdate و ExecuteDelete با یک مثال
فرض کنید مدلهای موجودیتهای برنامه شامل کلاسهای زیر هستند:
public class User { public int Id { get; set; } public required string FirstName { get; set; } public required string LastName { get; set; } public virtual List<Book> Books { get; set; } = new(); public virtual Address? Address { get; set; } } public class Book { public int Id { get; set; } public required string Type { get; set; } public required string Name { get; set; } public virtual User User { get; set; } = default!; public int UserId { get; set; } } public class Address { public int Id { get; set; } public required string Street { get; set; } public virtual User User { get; set; } = default!; public int UserId { get; set; } }
public class ApplicationDbContext : DbContext { public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) : base(options) { } public DbSet<User> Users { get; set; } = default!; public DbSet<Book> Books { get; set; } = default!; public DbSet<Address> Addresses { get; set; } = default!; }
مثال 1: حذف دستهای تعدادی کتاب
context.Books.Where(book => book.Name.Contains("1")).ExecuteDelete();
DELETE FROM [b] FROM [Books] AS [b] WHERE [b].[Name] LIKE N'%1%'
یک نکته: متد ExecuteDelete، تعداد رکوردهای حذف شده را نیز بازگشت میدهد.
مثال 2: حذف کاربران و تمام رکوردهای وابسته به آن
فرض کنید میخواهیم تعدادی از کاربران را از بانک اطلاعاتی حذف کنیم:
context.Users.Where(user => user.Id <= 500).ExecuteDelete();
DELETE FROM [u] FROM [Users] AS [u] WHERE [u].[Id] <= 500 The DELETE statement conflicted with the REFERENCE constraint "FK_Books_Users_UserId". The conflict occurred in database "EF7BulkOperations", table "dbo.Books", column 'UserId'.
public class ApplicationDbContext : DbContext { public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) : base(options) { } public DbSet<User> Users { get; set; } = default!; public DbSet<Book> Books { get; set; } = default!; public DbSet<Address> Addresses { get; set; } = default!; protected override void OnModelCreating(ModelBuilder modelBuilder) { base.OnModelCreating(modelBuilder); modelBuilder .Entity<User>() .HasMany(user => user.Books) .WithOne(book => book.User) .OnDelete(DeleteBehavior.Cascade); modelBuilder .Entity<User>() .HasOne(user => user.Address) .WithOne(address => address.User) .HasForeignKey<Address>(address => address.UserId) .OnDelete(DeleteBehavior.Cascade); } }
مثال 3: بهروز رسانی دستهای از کاربران
فرض کنید میخواهیم LastName تعدادی کاربر مشخص را به مقدار جدید Updated، تغییر دهیم:
context.Users.Where(user => user.Id <= 400) .ExecuteUpdate(p => p.SetProperty(user => user.LastName, user => "Updated"));
UPDATE [u] SET [u].[LastName] = N'Updated' FROM [Users] AS [u] WHERE [u].[Id] <= 400
context.Users.Where(user => user.Id <= 300) .ExecuteUpdate(p => p.SetProperty(user => user.LastName, user => "Updated" + user.LastName));
UPDATE [u] SET [u].[LastName] = N'Updated' + [u].[LastName] FROM [Users] AS [u] WHERE [u].[Id] <= 300
context.Users.Where(user => user.Id <= 800) .ExecuteUpdate(p => p.SetProperty(user => user.LastName, user => "Updated" + user.LastName) .SetProperty(user => user.FirstName, user => "Updated" + user.FirstName));
UPDATE [u] SET [u].[FirstName] = N'Updated' + [u].[FirstName], [u].[LastName] = N'Updated' + [u].[LastName] FROM [Users] AS [u] WHERE [u].[Id] <= 800
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید: EF7BulkOperations.zip
نظرات مطالب
تولید SiteMap استاندارد و ایجاد یک ActionResult اختصاصی برای Return کردن SiteMap تولید شده
- قسمتهای مختلف را کوئری میگیرید (یعنی به صورت پویا تولید میشود و نه اینکه جایی ثبت شوند)، union میکنید (چندین قسمت هست؟ مهم نیست. لیستهای تمام آنها باید به فرمت Sitemap نگاشت شده و یکی شوند) و نهایتا به صورت یک خروجی واحد ارائه میدهید. بحث لینکهای تکراری در اینجا مهم نیست (و مرتبط است به محتوای تکراری با آدرسهای مختلف در یک سایت و نه لینکهای سایتمپ). ممکن هست یک سایت در طول هفته اصلا رکورد جدیدی نداشته باشد. موتور جستجوگری که به آن میرسد یک سری لینک مشخص و تکراری را هر روز دریافت میکند و مدیریت ثبت آنها هم کاملا مشخص است و خودشان تکراری ثبت نمیکنند.
برای درک بهتر نحوهی ایندکس شدن sitemap نیاز هست به Google Webmaster Tools وب سایت خودتان را اضافه کنید و سپس token آنرا در سایت معرفی کنید. پس از مدتی میتوانید گزارش بگیرید که دقیقا چه مواردی را ثبت کردهاست و به چه نحوی.
- ضمنا امکان تعریف Sitemap index هم وجود دارد (جهت تعریف چندین سایتمپ در سایت). اطلاعات بیشتر در پروتکل آن آمادهاست. ولی در کل فرمت تولید آن سایتمپها هم به همین نحو استاندارد معرفی شدهاست. فقط در این حالت خاص که سایتمپ در ریشهی سایت قرار نمیگیرد و یا به آن اشاره نمیکند، محدود هستید به معرفی لینکهای همان پوشه و یا بازه.
برای درک بهتر نحوهی ایندکس شدن sitemap نیاز هست به Google Webmaster Tools وب سایت خودتان را اضافه کنید و سپس token آنرا در سایت معرفی کنید. پس از مدتی میتوانید گزارش بگیرید که دقیقا چه مواردی را ثبت کردهاست و به چه نحوی.
- ضمنا امکان تعریف Sitemap index هم وجود دارد (جهت تعریف چندین سایتمپ در سایت). اطلاعات بیشتر در پروتکل آن آمادهاست. ولی در کل فرمت تولید آن سایتمپها هم به همین نحو استاندارد معرفی شدهاست. فقط در این حالت خاص که سایتمپ در ریشهی سایت قرار نمیگیرد و یا به آن اشاره نمیکند، محدود هستید به معرفی لینکهای همان پوشه و یا بازه.
مطالب دورهها
متدهای توکار استفاده از نوع دادهای XML - قسمت دوم
امکان ترکیب دادههای یک بانک اطلاعاتی رابطهای و XML در SQL Server به کمک یک سری تابع کمکی خاص به نامهای sql:variable و sql:column پیش بینی شدهاست. sql:variable امکان استفاده از یک متغیر T-SQL را داخل یک XQuery میسر میسازد و توسط sql:column میتوان با یکی از ستونهای ذکر شده در قسمت select، داخل XQuery کار کرد. در ادامه به مثالهایی در این مورد خواهیم پرداخت.
ابتدا جدول xmlTest را به همراه چند رکورد ثبت شده در آن، درنظر بگیرید:
استفاده از متد sql:column
در ادامه میخواهیم مقدار ویژگی name رکوردی را که نام آن Vahid است، به همراه id آن ردیف، توسط یک XQuery بازگشت دهیم:
یک sql:column حتما نیاز به یک نام ستون دو قسمتی دارد. قسمت اول آن نام جدول است و قسمت دوم، نام ستون مورد نظر.
در مورد متد data در قسمت قبل بیشتر بحث شد و از آن برای استخراج دادهی یک ویژگی در اینجا استفاده شدهاست. عبارات داخل {} نیز پویا بوده و به همراه سایر قسمتهای ثابت return، ابتدا محاسبه و سپس بازگشت داده میشود.
اگر این کوئری را اجرا کنید، ردیف اول آن مساوی عبارت زیر خواهد بود
به همراه دو ردیف خالی دیگر در ادامه. این ردیفهای خالی به علت وجود دو رکورد دیگری است که با شرط where یاد شده تطابق ندارند.
یک روش برای حذف این ردیفهای خالی استفاده از متد exist است به شکل زیر:
در اینجا فقط ردیفی انتخاب خواهد شد که نام ویژگی آن Vahid است.
روش دوم استفاده از یک derived table و بازگشت ردیفهای غیرخالی است:
استفاده از متد sql:variable
در این مثال نحوهی بکارگیری یک متغیر T-SQL را داخل یک XQuery توسط متد sql:variable ملاحظه میکنید.
استفاده از For XML برای دریافت یکبارهی تمام ردیفهای XML
اگر کوئری معمولی ذیل را اجرا کنیم:
سه ردیف خروجی را مطابق سه رکوردی که ثبت کردیم، بازگشت میدهد.
اما اگر بخواهیم این سه ردیف را با هم ترکیب کرده و تبدیل به یک نتیجهی واحد کنیم، میتوان از For XML به نحو ذیل استفاده کرد:
بررسی متد xml.nodes
متد xml.nodes اندکی متفاوت است نسبت به تمام متدهایی که تاکنون بررسی کردیم. کار آن تجزیهی محتوای XML ایی به ستونها و سطرها میباشد. بسیار شبیه است به متد OpenXML اما کارآیی بهتری دارد.
در اینجا یک سند XML را درنظر بگیرید که از چندین نود شخص تشکیل شدهاست. اغلب آنها دارای یک name هستند. چهارمین نود، دو نام دارد و آخری بدون نام است.
در ادامه قصد داریم این اطلاعات را تبدیل به ردیفهایی کنیم که هر ردیف حاوی یک نام است. اولین سعی احتمالا استفاده از متد value خواهد بود:
این روش کار نمیکند زیرا متد value، بیش از یک مقدار را نمیتواند بازگشت دهد. البته میتوان از متد value به نحو زیر استفاده کرد:
اما حاصل آن دقیقا چیزی نیست که دنبالش هستیم؛ ما دقیقا نیاز به تمام نامها داریم و نه تنها یکی از آنها را.
سعی بعدی استفاده از متد query است:
در این حالت تمام نامها را بدست میآوریم:
اما این حاصل دو مشکل را به همراه دارد:
الف) خروجی آن XML است.
ب) تمام اینها در طی یک ردیف و یک ستون بازگشت داده میشوند.
و این خروجی نیز چیزی نیست که برای ما مفید باشد. ما به ازای هر شخص نیاز به یک ردیف جداگانه داریم. اینجا است که متد xml.nodes مفید واقع میشود:
خروجی متد xml.nodes یک table valued function است؛ یک جدول را باز میگرداند که دقیقا حاوی یک ستون میباشد. به همین جهت Alias آنرا با tab col مشخص کردهایم. tab متناظر است با جدول بازگشت داده شده و col متناظر است با تک ستون این جدول حاصل. این نامها در اینجا مهم نیستند؛ اما ذکر آنها اجباری است.
هر ردیف حاصل از این جدول بازگشت داده شده، یک اشارهگر است. به همین جهت نمیتوان آنها را مستقیما نمایش داد. هر سطر آن، به نودی که با آن مطابق XQuery وارد شده تطابق داشته است، اشاره میکند. در اینجا مطابق کوئری نوشته شده، هر ردیف به یک نود name اشاره میکند. در ادامه برای استخراج اطلاعات آن میتوان از متد text استفاده کرد.
اگر قصد داشتید، اطلاعات کامل نود ردیف جاری را مشاهده کنید میتوان از
استفاده کرد. دات در اینجا به معنای self است. دو دات (نقطه) پشت سرهم به معنای درخواست اطلاعات والد نود میباشد.
روش دیگر بدست آوردن مقدار یک نود را در کوئری ذیل مشاهده میکنید؛ value دات و data دات. خروجی value مقدار آن نود است و خروجی data مقدار آن نود با فرمت XML.
همچنین اگر بخواهیم اطلاعات تنها یک نود خاص را بدست بیاوریم، میتوان مانند کوئری ذیل عمل کرد:
در مورد کار با جداول، بجای متغیرهای T-SQL نیز روال کار به همین نحو است:
در اینجا یک جدول حاوی ستون XML ایی ایجاد شدهاست. سپس چهار ردیف در آن ثبت شدهاند. در آخر مقدار ویژگی نام این ردیفها بازگشت داده شدهاست.
نکته : استفادهی وسیع SQL Server از XML برای پردازش کارهای درونی آن
بسیاری از ابزارهایی که در نگارشهای جدید SQL Server اضافه شدهاند و یا مورد استفاده قرار میگیرند، استفادهی وسیعی از امکانات توکار XML آن دارند. مانند:
Showplan، گرافهای dead lock، گزارش پروسههای بلاک شده، اطلاعات رخدادها، SSIS Jobs، رخدادهای Trace و ...
مثال اول: کدام کوئریها در Plan cache، کارآیی پایینی داشته و table scan را انجام میدهند؟
اطلاعات Query Plan در SQL Server با فرمت XML ارائه میشود. در اینجا میخواهیم یک سری متغیر مانند Clustered Index Scan و امثال آنرا از ویژگی PhysicalOp آن کوئری بگیریم. بنابراین از متد sql:variable کمک گرفته شدهاست.
اگر علاقمند هستید که اصل این اطلاعات را با فرمت XML مشاهده کنید، کوئری نوشته شده را تا پیش از where آن یکبار مستقلا اجرا کنید. ستون آخر آن query_plan نام دارد و حاوی اطلاعات XML ایی است.
مثال دوم: استخراج اپراتورهای رابطهای (RelOp) از یک Query Plan ذخیره شده
در اینجا کار کردن با WITH XMLNAMESPACES در حین استفاده از متد xml.nodes سادهتر است؛ بجای قرار دادن فضای نام در تمام کوئریهای نوشته شده.
بررسی متد xml.modify
تا اینجا تمام کارهایی که صورت گرفت و نکاتی که بررسی شدند، به مباحث select اختصاص داشتند. اما insert، delete و یا update قسمتی از یک سند XML بررسی نشدند. برای این منظور باید از متد xml.modify استفاده کرد. از آن در عبارات update و یا set کمک گرفته شده و ورودی آن نباید نال باشد. در ادامه در طی مثالهایی این موارد را بررسی خواهیم کرد.
ابتدا فرض کنید که سند XML ما چنین شکلی را دارا است:
در ادامه قصد داریم یک نود جدید را پس از CustomerName اضافه کنیم.
اینکار را با استفاده از دستور insert، به نحو فوق میتوان انجام داد. از عبارت Set و متغیر doc مقدار دهی شده، کار شروع شده و سپس نود جدیدی پس از (after) اولین نود CustomerName موجود insert میشود. Select بعدی نتیجه را نمایش خواهد داد.
در SQL Server 2008 به بعد، امکان استفاده از متغیرهای T-SQL نیز در اینجا مجاز شدهاست:
بنابراین اگر نیاز به تعریف متغیری در اینجا داشتید از جمع زدن رشتهها استفاده نکنید. حتما نیاز است متغیر تعریف شود و گرنه باخطای ذیل متوقف خواهید شد:
افزودن ویژگیهای جدید به یک سند XML توسط متد xml.modify
اگر بخواهیم یک ویژگی (attribute) جدید را به نود خاصی اضافه کنیم میتوان به نحو ذیل عمل کرد:
که خروجی دو سطر ابتدایی آن پس از اضافه شدن ویژگی status با مقدار backorder به نحو ذیل است:
حذف نودهای یک سند XML توسط متد xml.modify
اگر بخواهیم تمام LineItemها را حذف کنیم میتوان نوشت:
با این خروجی:
به روز رسانی نودهای یک سند XML توسط متد xml.modify
اگر نیاز باشد تا مقدار یک نود را تغییر دهیم میتوان از replace value of استفاده کرد:
با خروجی ذیل که در آن نام اولین مشتری با مقدار Farid جایگزین شده است:
replace value of فقط با یک نود کار میکند و همچنین، فقط مقدار آن نود را تغییر میدهد. به همین جهت از متد text استفاده شدهاست. اگر از text استفاده نشود با خطای ذیل متوقف خواهیم شد:
به روز رسانی نودهای خالی توسط متد xml.modify
باید دقت داشت، نودهای خالی (بدون مقدار)، مانند LineItems پس از delete کلیه اعضای آن در مثال قبل، قابل replace نیستند و باید مقادیر جدید را در آنها insert کرد. یک مثال:
در این مثال اگر از replace value of برای مقدار دهی نود سوم استفاده میشد:
تغییری را پس از اعمال دستورات مشاهده نمیکردید؛ زیرا این المان ()text ایی را برای replace شدن ندارد.
ابتدا جدول xmlTest را به همراه چند رکورد ثبت شده در آن، درنظر بگیرید:
CREATE TABLE xmlTest ( id INT IDENTITY PRIMARY KEY, doc XML ) GO INSERT xmlTest VALUES('<Person name="Vahid" />') INSERT xmlTest VALUES('<Person name="Farid" />') INSERT xmlTest VALUES('<Person name="Mehdi" /><Person name="Hamid" />') GO
استفاده از متد sql:column
در ادامه میخواهیم مقدار ویژگی name رکوردی را که نام آن Vahid است، به همراه id آن ردیف، توسط یک XQuery بازگشت دهیم:
SELECT doc.query(' for $p in //Person where $p/@name="Vahid" return <li>{data($p/@name)} has id = {sql:column("xmlTest.id")}</li> ') FROM xmlTest
در مورد متد data در قسمت قبل بیشتر بحث شد و از آن برای استخراج دادهی یک ویژگی در اینجا استفاده شدهاست. عبارات داخل {} نیز پویا بوده و به همراه سایر قسمتهای ثابت return، ابتدا محاسبه و سپس بازگشت داده میشود.
اگر این کوئری را اجرا کنید، ردیف اول آن مساوی عبارت زیر خواهد بود
<li>Vahid has id = 1</li>
یک روش برای حذف این ردیفهای خالی استفاده از متد exist است به شکل زیر:
SELECT doc.query(' for $p in //Person where $p/@name="Vahid" return <li>{data($p/@name)} has id = {sql:column("xmlTest.id")}</li> ') FROM xmlTest WHERE doc.exist(' for $p in //Person where $p/@name="Vahid" return <li>{data($p/@name)} has id = {sql:column("xmlTest.id")}</li> ')=1
روش دوم استفاده از یک derived table و بازگشت ردیفهای غیرخالی است:
SELECT * FROM ( (SELECT doc.query(' for $p in //Person where $p/@name="Vahid" return <li>{data($p/@name)} has id = {sql:column("xmlTest.id")}</li> ') AS col1 FROM xmlTest) ) A WHERE CONVERT(VARCHAR(8000), col1)<>''
استفاده از متد sql:variable
DECLARE @number INT = 1 SELECT doc.query(' for $p in //Person where $p/@name="Vahid" return <li>{data($p/@name)} has number = {sql:variable("@number")}</li> ') FROM xmlTest
استفاده از For XML برای دریافت یکبارهی تمام ردیفهای XML
اگر کوئری معمولی ذیل را اجرا کنیم:
SELECT doc.query('/Person') FROM xmlTest
اما اگر بخواهیم این سه ردیف را با هم ترکیب کرده و تبدیل به یک نتیجهی واحد کنیم، میتوان از For XML به نحو ذیل استفاده کرد:
DECLARE @doc XML SET @doc = (SELECT * FROM xmlTest FOR XML AUTO, ELEMENTS) SELECT @doc.query('/xmlTest/doc/Person')
بررسی متد xml.nodes
متد xml.nodes اندکی متفاوت است نسبت به تمام متدهایی که تاکنون بررسی کردیم. کار آن تجزیهی محتوای XML ایی به ستونها و سطرها میباشد. بسیار شبیه است به متد OpenXML اما کارآیی بهتری دارد.
DECLARE @doc XML =' <people> <person><name>Vahid</name></person> <person><name id="2">Farid</name></person> <person><name>Mehdi</name></person> <person><name>Hooshang</name><name id="1">Hooshi</name></person> <person></person> </people> '
در ادامه قصد داریم این اطلاعات را تبدیل به ردیفهایی کنیم که هر ردیف حاوی یک نام است. اولین سعی احتمالا استفاده از متد value خواهد بود:
SELECT @doc.value('/people/person/name', 'varchar(50)')
SELECT @doc.value('(/people/person/name)[1]', 'varchar(50)')
سعی بعدی استفاده از متد query است:
SELECT @doc.query('/people/person/name')
<name>Vahid</name> <name id="2">Farid</name> <name>Mehdi</name> <name>Hooshang</name> <name id="1">Hooshi</name>
الف) خروجی آن XML است.
ب) تمام اینها در طی یک ردیف و یک ستون بازگشت داده میشوند.
و این خروجی نیز چیزی نیست که برای ما مفید باشد. ما به ازای هر شخص نیاز به یک ردیف جداگانه داریم. اینجا است که متد xml.nodes مفید واقع میشود:
SELECT tab.col.value('text()[1]', 'varchar(50)') AS name, tab.col.query('.'), tab.col.query('..') from @doc.nodes('/people/person/name') AS tab(col)
هر ردیف حاصل از این جدول بازگشت داده شده، یک اشارهگر است. به همین جهت نمیتوان آنها را مستقیما نمایش داد. هر سطر آن، به نودی که با آن مطابق XQuery وارد شده تطابق داشته است، اشاره میکند. در اینجا مطابق کوئری نوشته شده، هر ردیف به یک نود name اشاره میکند. در ادامه برای استخراج اطلاعات آن میتوان از متد text استفاده کرد.
اگر قصد داشتید، اطلاعات کامل نود ردیف جاری را مشاهده کنید میتوان از
tab.col.query('.'),
روش دیگر بدست آوردن مقدار یک نود را در کوئری ذیل مشاهده میکنید؛ value دات و data دات. خروجی value مقدار آن نود است و خروجی data مقدار آن نود با فرمت XML.
SELECT tab.col.value('.', 'varchar(50)') AS name, tab.col.query('data(.)'), tab.col.query('.'), tab.col.query('..') from @doc.nodes('/people/person/name') AS tab(col)
همچنین اگر بخواهیم اطلاعات تنها یک نود خاص را بدست بیاوریم، میتوان مانند کوئری ذیل عمل کرد:
SELECT tab.col.value('name[.="Farid"][1]', 'varchar(50)') AS name, tab.col.value('name[.="Farid"][1]/@id', 'varchar(50)') AS id, tab.col.query('.') from @doc.nodes('/people/person[name="Farid"]') AS tab(col)
در مورد کار با جداول، بجای متغیرهای T-SQL نیز روال کار به همین نحو است:
DECLARE @tblXML TABLE ( id INT IDENTITY PRIMARY KEY, doc XML ) INSERT @tblXML VALUES('<person name="Vahid" />') INSERT @tblXML VALUES('<person name="Farid" />') INSERT @tblXML VALUES('<person />') INSERT @tblXML VALUES(NULL) SELECT id, doc.value('(/person/@name)[1]', 'varchar(50)') AS name FROM @tblXML
نکته : استفادهی وسیع SQL Server از XML برای پردازش کارهای درونی آن
بسیاری از ابزارهایی که در نگارشهای جدید SQL Server اضافه شدهاند و یا مورد استفاده قرار میگیرند، استفادهی وسیعی از امکانات توکار XML آن دارند. مانند:
Showplan، گرافهای dead lock، گزارش پروسههای بلاک شده، اطلاعات رخدادها، SSIS Jobs، رخدادهای Trace و ...
مثال اول: کدام کوئریها در Plan cache، کارآیی پایینی داشته و table scan را انجام میدهند؟
CREATE PROCEDURE LookForPhysicalOps (@op VARCHAR(30)) AS SELECT sql.text, qs.EXECUTION_COUNT, qs.*, p.* FROM sys.dm_exec_query_stats AS qs CROSS APPLY sys.dm_exec_sql_text(sql_handle) sql CROSS APPLY sys.dm_exec_query_plan(plan_handle) p WHERE query_plan.exist(' declare default element namespace "http://schemas.microsoft.com/sqlserver/2004/07/showplan"; /ShowPlanXML/BatchSequence/Batch/Statements//RelOp/@PhysicalOp[. = sql:variable("@op")] ') = 1 GO EXECUTE LookForPhysicalOps 'Table Scan' EXECUTE LookForPhysicalOps 'Clustered Index Scan' EXECUTE LookForPhysicalOps 'Hash Match'
اگر علاقمند هستید که اصل این اطلاعات را با فرمت XML مشاهده کنید، کوئری نوشته شده را تا پیش از where آن یکبار مستقلا اجرا کنید. ستون آخر آن query_plan نام دارد و حاوی اطلاعات XML ایی است.
مثال دوم: استخراج اپراتورهای رابطهای (RelOp) از یک Query Plan ذخیره شده
WITH XMLNAMESPACES(DEFAULT N'http://schemas.microsoft.com/sqlserver/2004/07/showplan') SELECT RelOp.op.value(N'../../@NodeId', N'int') AS ParentOperationID, RelOp.op.value(N'@NodeId', N'int') AS OperationID, RelOp.op.value(N'@PhysicalOp', N'varchar(50)') AS PhysicalOperator, RelOp.op.value(N'@LogicalOp', N'varchar(50)') AS LogicalOperator, RelOp.op.value(N'@EstimatedTotalSubtreeCost ', N'float') AS EstimatedCost, RelOp.op.value(N'@EstimateIO', N'float') AS EstimatedIO, RelOp.op.value(N'@EstimateCPU', N'float') AS EstimatedCPU, RelOp.op.value(N'@EstimateRows', N'float') AS EstimatedRows, cp.plan_handle AS PlanHandle, st.TEXT AS QueryText, qp.query_plan AS QueryPlan, cp.cacheobjtype AS CacheObjectType, cp.objtype AS ObjectType FROM sys.dm_exec_cached_plans cp CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) st CROSS APPLY sys.dm_exec_query_plan(cp.plan_handle) qp CROSS APPLY qp.query_plan.nodes(N'//RelOp') RelOp(op)
بررسی متد xml.modify
تا اینجا تمام کارهایی که صورت گرفت و نکاتی که بررسی شدند، به مباحث select اختصاص داشتند. اما insert، delete و یا update قسمتی از یک سند XML بررسی نشدند. برای این منظور باید از متد xml.modify استفاده کرد. از آن در عبارات update و یا set کمک گرفته شده و ورودی آن نباید نال باشد. در ادامه در طی مثالهایی این موارد را بررسی خواهیم کرد.
ابتدا فرض کنید که سند XML ما چنین شکلی را دارا است:
DECLARE @doc XML = ' <Invoice> <InvoiceId>100</InvoiceId> <CustomerName>Vahid</CustomerName> <LineItems> <LineItem> <Sku>134</Sku> <Quantity>10</Quantity> <Description>Item 1</Description> <UnitPrice>9.5</UnitPrice> </LineItem> <LineItem> <Sku>150</Sku> <Quantity>5</Quantity> <Description>Item 2</Description> <UnitPrice>1.5</UnitPrice> </LineItem> </LineItems> </Invoice> '
SET @doc.modify(' insert <InvoiceInfo><InvoiceDate>2014-02-10</InvoiceDate></InvoiceInfo> after /Invoice[1]/CustomerName[1] ') SELECT @doc
<Invoice> <InvoiceId>100</InvoiceId> <CustomerName>Vahid</CustomerName> <InvoiceInfo> <InvoiceDate>2014-02-10</InvoiceDate> </InvoiceInfo> <LineItems> ...
در SQL Server 2008 به بعد، امکان استفاده از متغیرهای T-SQL نیز در اینجا مجاز شدهاست:
SET @x.modify('insert sql:variable("@x") into /doc[1]')
The argument 1 of the XML data type method "modify" must be a string literal.
افزودن ویژگیهای جدید به یک سند XML توسط متد xml.modify
اگر بخواهیم یک ویژگی (attribute) جدید را به نود خاصی اضافه کنیم میتوان به نحو ذیل عمل کرد:
SET @doc.modify(' insert attribute status{"backorder"} into /Invoice[1] ') SELECT @doc
<Invoice status="backorder"> <InvoiceId>100</InvoiceId> ....
حذف نودهای یک سند XML توسط متد xml.modify
اگر بخواهیم تمام LineItemها را حذف کنیم میتوان نوشت:
SET @doc.modify('delete /Invoice/LineItems/LineItem') SELECT @doc
<Invoice status="backorder"> <InvoiceId>100</InvoiceId> <CustomerName>Vahid</CustomerName> <InvoiceInfo> <InvoiceDate>2014-02-10</InvoiceDate> </InvoiceInfo> <LineItems /> </Invoice>
به روز رسانی نودهای یک سند XML توسط متد xml.modify
اگر نیاز باشد تا مقدار یک نود را تغییر دهیم میتوان از replace value of استفاده کرد:
SET @doc.modify('replace value of /Invoice[1]/CustomerName[1]/text()[1] with "Farid" ') SELECT @doc
<Invoice status="backorder"> <InvoiceId>100</InvoiceId> <CustomerName>Farid</CustomerName> <InvoiceInfo> <InvoiceDate>2014-02-10</InvoiceDate> </InvoiceInfo> <LineItems /> </Invoice>
The target of 'replace value of' must be a non-metadata attribute or an element with simple typed content.
به روز رسانی نودهای خالی توسط متد xml.modify
باید دقت داشت، نودهای خالی (بدون مقدار)، مانند LineItems پس از delete کلیه اعضای آن در مثال قبل، قابل replace نیستند و باید مقادیر جدید را در آنها insert کرد. یک مثال:
DECLARE @tblTest AS TABLE (xmlField XML) INSERT INTO @tblTest(xmlField) VALUES ( '<Sample> <Node1>Value1</Node1> <Node2>Value2</Node2> <Node3/> </Sample>' ) DECLARE @newValue VARCHAR(50) = 'NewValue' UPDATE @tblTest SET xmlField.modify( 'insert text{sql:variable("@newValue")} into (/Sample/Node3)[1] [not(text())]' ) SELECT xmlField.value('(/Sample/Node3)[1]','varchar(50)') FROM @tblTest
UPDATE @tblTest SET xmlField.modify( 'replace value of (/Sample/Node3/text())[1] with sql:variable("@newValue")' )
باید از از حالت INSTEAD OF استفاده کنیم در DML Trigger ای که قراره نوشته بشه.
میتوانیم در یک جدول از دیتابیس مان بر اساس یک شرط خاص, عملیات Insert,Delete,Update را مدیریت کنیم.
بعنوان مثال در قطعه کد زیر ما قبل از عملیات Insert در جدول tblTest چک میکنیم که اگر مقدار ستون FirstName برابر با null بود عملیات Insert آن رکورد در دیتابیس لغو شود.
از دو طریق میتوان به مقادیر فیلدهای رکورد جاری دسترس داشت:
1- استفاده از OBJECT_ID و ذکر نام فیلد مورد نظر
2- گرفتن فیلد مورد نظر از جدول INSERTED یا DELETED
DML Triggerها دارای دو جدول خاص بنامهای INSERTED و DELETED هستند که توسط خود SQL Server مدیریت میشوند.در حقیقت در پشت صحنه, ما با این دو جدول در هنگام تغییر مقادیر دادههای جداول دیتابیس کار میکنیم و نمیتوانیم بصورت مستقیم دادههای جداول موجود در دیتا بیس مان را تغییر دهیم.
جدول INSERTED و DELETED حاوی رکورد جاری است که تحت تاثیر عمل درج, ویرایش و حذف در دیتابیس قرار گرفته است.
اطلاعات بیشتر در اینجا و اینجا
میتوانیم در یک جدول از دیتابیس مان بر اساس یک شرط خاص, عملیات Insert,Delete,Update را مدیریت کنیم.
بعنوان مثال در قطعه کد زیر ما قبل از عملیات Insert در جدول tblTest چک میکنیم که اگر مقدار ستون FirstName برابر با null بود عملیات Insert آن رکورد در دیتابیس لغو شود.
ALTER TRIGGER [dbo].[Prevent_Befor_Insert_Null] ON [dbTest].[dbo].[tblTest] INSTEAD OF INSERT AS BEGIN SET NOCOUNT ON IF OBJECT_ID(N'dbTest.dbo.tblTest.FirstName') is null BEGIN DECLARE @Id int SET @Id = (select Id from inserted) RAISERROR ('مقدار فیلد نام نباید خالی باشد',16,1) ROLLBACK END END
از دو طریق میتوان به مقادیر فیلدهای رکورد جاری دسترس داشت:
1- استفاده از OBJECT_ID و ذکر نام فیلد مورد نظر
2- گرفتن فیلد مورد نظر از جدول INSERTED یا DELETED
DML Triggerها دارای دو جدول خاص بنامهای INSERTED و DELETED هستند که توسط خود SQL Server مدیریت میشوند.در حقیقت در پشت صحنه, ما با این دو جدول در هنگام تغییر مقادیر دادههای جداول دیتابیس کار میکنیم و نمیتوانیم بصورت مستقیم دادههای جداول موجود در دیتا بیس مان را تغییر دهیم.
جدول INSERTED و DELETED حاوی رکورد جاری است که تحت تاثیر عمل درج, ویرایش و حذف در دیتابیس قرار گرفته است.
اطلاعات بیشتر در اینجا و اینجا
SQL Server Corruption Recovery - When All Else Fails
تکنیکهایی برای برگرداندن اطلاعات از فایلهای SQL Server که خسارت دیده اند و خراب شده اند و از بخت بد، فایل Backup یا موجود نیست و یا روشهای معمول برگرداندن اطلاعات درست کار نمیکنند.
در این تمرین بانک اطلاعاتی نمونه AdventureWorksLT2008R2 بکار گرفته شده است.
در این تکنیک از کلاس RawDatabase که در پروژه منبع باز OrcaMDF که یک پارسر (Parser) تحت زبان #C برای خواندن فایلهای mdf. بانک اطلاعاتی SQL Server بدون Attach کردن یا اجرای SQL Server میباشد استفاده شده است.
حتی اگر تمام امیدتان را برای برگرداندن اطلاعات از دست داده اید ، هنوز هم گزینه های وجود دارد . ابزار OrcaMDF یا راه حلهای دیگر ممکن است به دلیل یک فاجعه به صورت یک ابزار ارزشمند درآمده باشد. البته این یک جایگزین خوب برای برگرداندن اطلاعات نیست.
تکنیکهایی برای برگرداندن اطلاعات از فایلهای SQL Server که خسارت دیده اند و خراب شده اند و از بخت بد، فایل Backup یا موجود نیست و یا روشهای معمول برگرداندن اطلاعات درست کار نمیکنند.
در این تمرین بانک اطلاعاتی نمونه AdventureWorksLT2008R2 بکار گرفته شده است.
در این تکنیک از کلاس RawDatabase که در پروژه منبع باز OrcaMDF که یک پارسر (Parser) تحت زبان #C برای خواندن فایلهای mdf. بانک اطلاعاتی SQL Server بدون Attach کردن یا اجرای SQL Server میباشد استفاده شده است.
حتی اگر تمام امیدتان را برای برگرداندن اطلاعات از دست داده اید ، هنوز هم گزینه های وجود دارد . ابزار OrcaMDF یا راه حلهای دیگر ممکن است به دلیل یک فاجعه به صورت یک ابزار ارزشمند درآمده باشد. البته این یک جایگزین خوب برای برگرداندن اطلاعات نیست.
با سلام
من روی یه پروژه مالی دارم با ASP WebForm کار میکنم و میخواستم در اول هر ماه یک سری دستورات ویرایش یا update را که به صورت رکورد در یک جدول ذخیره میکنم انجام بشن. سوالم اینه که برای این که مجموعه دستورات من انجام بشن باید برنامه جتما Run باشه و چه جوری میشه اونو به صورت پس زمینه در حال اجرا نگه داشت.
با تشکر
بعد از ایجاد یک جدول بهینه سازی شده برای حافظه، هر یک دقیقه یک خطا در لاگ پایگاه داده ثبت میشه با این عنوان:
Disallowing page allocations for database 'MyDatabase' due to insufficient memory in the resource pool 'default'. See 'http://go.microsoft.com/fwlink/?LinkId=510837' for more information.
با توجه به لینکی که داده Resource governor رو هم فعال کردم ولی مشکل حل نشد.
مشخصات سیستم:
OS: Windows 10
Database: SQL Server 2017 - Resource governor is enable
Hardware: Dedicated local system with 16 GB RAM
اگر به Entity data model wizard در VS.Net 2010 دقت کرده باشید، گزینهی "Pluralize or singularize generated object names" نیز به آن اضافه شده است:
این مورد از این جهت حائز اهمیت است که عموما نام جداول در بانک اطلاعاتی، جمع است و نام کلاس متناظر ایجاد شده برای آن در کدهای برنامه بهتر است مفرد باشد. برای مثال نام جدول، Customers است و نام کلاس آن بهتر است Customer تعریف گردد. به این صورت کار کردن با آن توسط یک ORM با معناتر خواهد بود؛ زیرا زمانیکه یک وهله از شیء Customer ایجاد میشود، فقط یک رکورد از بانک اطلاعاتی مد نظر است؛ در حالیکه یک جدول مجموعهای است از رکوردها.
زبان انگلیسی هم پر است از اسامی جمع و مفرد باقاعده و بیقاعده و کل عملیات با اضافه و حذف کردن یک s و یا es پایان نمییابد؛ برای مثال phenomenon و phenomena را در نظر بگیرد تا Money و Moneys.
این امکان مهیا شده توسط Entity Framework 4.0 یا همان EF v2 با برنامه نویسی هم قابل دسترسی است و در اسمبلی System.Data.Entity.Design.dll و فضای نام System.Data.Entity.Design.PluralizationServices قرار گرفته است.
این اسمبلی جزیی از دات نت 4 است و اگر آنرا توسط گزینهی Add references در VS.NET مشاهده نمیکنید، علت آن است که در تنظیمات پروژه جاری، گزینهی Target framework بر روی Client profile قرار گرفته است که باید به دات نت 4 کامل تغییر یابد.
استفاده از آن هم به صورت زیر است:
using System;
using System.Data.Entity.Design.PluralizationServices;
using System.Globalization;
namespace PluralizationServicesTest
{
class Program
{
static void Main(string[] args)
{
var service = PluralizationService.CreateService(CultureInfo.GetCultureInfo("en"));
Console.WriteLine(service.Pluralize("mouse"));
Console.WriteLine(service.IsPlural("phenomena"));
}
}
}
ملاحظات:
این روش فعلا به زبان انگلیسی محدود است و اگر Culture را به مورد دیگری تنظیم کنید با خطای "We don't support locales other than English yet" متوقف خواهید شد.
روش دیگر:
کتابخانهی سورس باز Castle ActiveRecord نیز دارای کلاسی است به نام Inflector که برای همین منظور طراحی شده است:
کاربرد آن در Fluent NHibernate
در Fluent NHibernate کار نگاشت کلاسها به جداول به صورت خودکار صورت میگیرد و همچنین تولید ساختار بانک اطلاعاتی نیز به همین نحو میباشد. اما میتوان تولید نام جداول را سفارشی نیز نمود. برای مثال از کلاس Book به صورت خودکار ساختار جدولی به نام Books را تولید کند:
using FluentNHibernate.Conventions;
using FluentNHibernate.Conventions.Instances;
using NHibernate.Helper.Toolkit;
namespace NHibernate.Helper.MappingConventions
{
public class TableNameConvention : IClassConvention
{
public void Apply(IClassInstance instance)
{
instance.Table(Inflector.Pluralize(instance.EntityType.Name));
}
}
}
... = new AutoPersistenceModel()
.Where(...)
.Conventions.Setup(c =>c.Add<TableNameConvention>())
.AddEntityAssembly(...)
...