Microsoft's .NET Fundamentals Team a few weeks ago announced a new version of .NET Framework 4.6.1. It includes a number of streamline improvements to Windows Presentation Foundation and SQL Connectivity, to name a few. And just recently, the team also re-emphasized end of support for versions of .NET Framework versions older than 4.5.1.
We are extremely excited to announce the general availability of EF Core 3.0and EF 6.3 on nuget.org .
What’s new in EF Core 3.0
Including major features, minor enhancements, and bug fixes, EF Core 3.0 contains more than 600 product improvements. Here are some of the most important ones:
- LINQ overhaul
- Restricted client evaluation
- Single SQL statement per LINQ query
- Cosmos DB support
- C# 8.0 support (Asynchronous streams, Nullable reference types)
- Interception of database operations
- Reverse engineering of database views
- Dependent entities sharing a table with principal are now optional
اشتراکها
Full-Text Search در MongoDB
MongoDB, one of the leading NoSQL databases, is well known for its fast performance, flexible schema, scalability and great indexing capabilities. At the core of this fast performance lies MongoDB indexes, which support efficient execution of queries by avoiding full-collection scans and hence limiting the number of documents MongoDB searches.
Starting from version 2.4, MongoDB began with an experimental feature supporting Full-Text Search using Text Indexes .
اشتراکها
انتشار automapper نسخه 9.0
اشتراکها
ده قانون برای کدنویسی امن
نوعهای Generics در دات نت از اعمال ریاضی مانند جمع و ضرب و منها پشتیبانی نمیکنند. در مقالات ذیل راه حلهایی برای رفع این مشکل ارائه شدهاند که میتوانند تبدیل به یک مقاله جدید گردند:
اشتراکها
برنامه نویسی چند هسته ای در .NET
عموما اولین پاسخی که به این سؤال داده میشود این است که این نوع کوئریها اطلاعات زیادی را باز میگردانند و در نتیجه ترافیک شبکه بیجهت افزایش خواهد یافت. اما اگر طراحی دیتابیس صحیح بوده و اصول نرمال سازی در آن پیاده سازی شده باشد، این پاسخ آنچنان صادق نخواهد بود (زیرا جداول اینگونه دیتابیسها از تعداد فیلدهای بسیاری تشکیل نخواهند شد). برای مثال به نتیجه اجرای کوئریهای زیر بر روی دیتابیس AdventureWorks با 89 هزار رکورد، دقت بفرمائید:
SELECT * FROM Production.TransactionHistoryArchive
WHERE ReferenceOrderID < 100
SELECT ReferenceOrderLineID FROM Production.TransactionHistoryArchive
WHERE ReferenceOrderID < 100
مهمترین دلیلی که اینجا باید به آن دقت داشت، تفاوت چشمگیر execution plan این دو کوئری (Ctrl-L) و بحث index coverage است. اس کیوال سرور برای اجرای بهینه کوئریها از ایندکسهای موجود استفاده خواهد کرد. اگر ایندکس تعریف شده از تمامی فیلدهای درخواستی شما تشکیل شده باشد، دیگر حتی به سراغ جدول هم نخواهد رفت (به این مفهوم، پوشش ایندکسی گفته میشود).
برای تولید تصویر فوق، کلیدهای Ctrl+L را در management studio فشار دهید.
این دیتابیس را از آدرس زیر میتوانید دریافت کنید:
http://www.codeplex.com/MSFTDBProdSamples
کوئری اول از مزایای پوشش ایندکسی برخودار نخواهد بود (از روش جستجوی Clustered Index استفاده میکند) و در حالت دوم از Index Seek استفاده میگردد. حالت Index Seek یکصد بار بهینهتر از استفاده از Clustered Index عمل میکند زیرا در حالت کوئری اول باید تمامی رکوردهای جدول بررسی شوند (این عدد از مقایسه نتایج execution plan بدست آمده است).
تنها در صورتیکه بر روی تمامی فیلدهای جدول ایندکس تعریف کرده باشید (که اصلا توصیه نمیشود)، کوئری اول توسط ایندکسها پوشش داده شده و سریع اجرا خواهد شد.
بنابراین اگر از کندی اجرای کوئریها با تعداد رکورد بالا شکایت دارید بهتر است نگاهی به نحوه تعریف آنها داشته باشید و تنها فیلدهایی را در کوئری تعریف کنید که به آنها نیاز دارید. در این حالت از مزایای پوشش ایندکسی برخودار شده ، کوئریهای سریعتری را خواهید داشت و همچنین در این حالت میزان مصرف CPU و حافظه نیز بر روی سرور کمتر خواهد بود.
همچنین در حالت کوئریهایی از نوع دوم ذکر شده، موتور بهینه ساز اس کیوال سرور پیشنهادات بهتری را برای ایجاد ایندکسهای جدید و گوشزد نمودن کمبود آنها با ارائه included columns مناسب، ارائه میدهد.
بعلاوه مشخص ساختن تعداد دقیق فیلدهای مورد نیاز، نگهداری برنامه را سادهتر ساخته و فیلدهای اضافه شده آتی سبب تغییر رفتار کوئریها برنامه نخواهند شد و استفاده نکردن از آن نشانه این است که هیچ برآوردی از ابعاد واقعی کار در دست نیست.
مآخذ:
Speed Up Your Site! 8 ASP.NET Performance Tips
The real reason SELECT * queries are bad: index coverage