Enumها به عنوان رشته در EF Core:
کدی خواناتر برای دیتابیس شما 📜

وقتی از Enumها در Entity Framework Core استفاده می‌کنید، به صورت پیش‌فرض به شکل عدد (0, 1, 2) در دیتابیس ذخیره میشن. این کار از نظر پرفورمنس خوبه، ولی وقتی مستقیم به دیتابیس نگاه می‌کنید، این عددها هیچ معنایی ندارن! 🧐

اما یه راه حل خیلی ساده و تمیز برای افزایش خوانایی و قابلیت نگهداری دیتابیس وجود داره: ذخیره کردن Enumها به صورت رشته.

جادوی HasConversion ✨

با استفاده از متد HasConversion در Fluent API، می‌تونید به راحتی به EF Core بگید که مقادیر Enum رو به جای عدد، به صورت نام رشته‌ای اون‌ها ذخیره کنه.

1️⃣ Enum شما:

public enum OrderStatus 
{
    Pending,
    Completed,
    Cancelled 
}

2️⃣ انتیتی شما:

public class Order 
{
    public int Id { get; set; }
    public OrderStatus Status { get; set; }
}

3️⃣ پیکربندی در DbContext:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Order>()
        .Property(o => o.Status)
        .HasConversion<string>(); // تمام جادو اینجاست!
}

حالت پیش‌فرض (بدون HasConversion): 👎

| Id | Status |
| :-- | :--- |
| 1 | 0 |
| 2 | 1 |

حالت جدید (با HasConversion): 👍

| Id | Status |
| :-- | :--- |
| 1 | "Pending" |
| 2 | "Completed" |

🤔 حرف حساب و تجربه شما
این تغییر کوچیک، دیباگ کردن و کار مستقیم با دیتابیس رو خیلی راحت‌تر می‌کنه. با اینکه ذخیره‌سازی به صورت عدد کمی بهینه‌تره، اما در اکثر پروژه‌ها، خوانایی بالاتر Enum به صورت رشته، ارزشش رو داره.

</Link>

🔖 هشتگ‌ها:
#EntityFrameworkCore #EFCore #Database

5️⃣ Eager Loading (بارگذاری مشتاقانه) ⏬

بارگذاری مشتاقانه قابلیتی در EF Core است که به شما اجازه می‌دهد انتیتی‌های مرتبط را به همراه انتیتی اصلی خود در یک کوئری دیتابیس واحد بارگذاری کنید.

internal sealed class 
VerifyEmail(AppDbContext context)
{
    public async Task<bool> Handle(Guid tokenId)
    {
        EmailVerificationToken? token = await context.EmailVerificationTokens
            .Include(e => e.User) // User مرتبط را همزمان لود کن
            .FirstOrDefaultAsync(e => e.Id == tokenId);
        
        // ...
    }
}

EF Core
یک کوئری SQL واحد تولید می‌کند که جداول EmailVerificationToken و User را join می‌کند.

خلاصه 📝

پس، این هم از این! پنج ویژگی EF Core که، صراحتاً، نمی‌توانید از ندانستنشان شانه خالی کنید. به یاد داشته باشید، تسلط بر EF Core زمان می‌برد، اما این ویژگی‌ها یک پایه محکم برای ساختن فراهم می‌کنند.

یک توصیه دیگر این است که عمیقاً درک کنید دیتابیس شما چگونه کار می‌کند. تسلط بر SQL همچنین به شما اجازه می‌دهد بیشترین ارزش را از EF Core بدست آورید.

🔖 هشتگ‌ها:
#EntityFrameworkCore #EFCore #Performance #Database #SQL

متد HasFilter فیلتر SQL را برای رکوردهایی که در ایندکس قرار خواهند گرفت، می‌پذیرد.
شما همچنین می‌توانید یک ایندکس فیلتر شده را با استفاده از SQL ایجاد کنید:

CREATE INDEX IX_Reviews_IsDeleted
ON bookings.Reviews (IsDeleted)
WHERE IsDeleted = 0;

شما می‌توانید از طریق مستندات، اطلاعات بیشتری در مورد ایندکس‌های فیلتر شده کسب کنید.

آیا واقعاً به حذف نرم نیاز دارید؟ 🤔

ارزشش را دارد که فکر کنید آیا اصلاً به حذف نرم رکوردها نیاز دارید یا خیر.
در سیستم‌های سازمانی (enterprise)، شما معمولاً به "حذف" داده فکر نمی‌کنید. مفاهیم تجاری وجود دارند که شامل حذف داده نمی‌شوند. چند مثال عبارتند از: لغو یک سفارش، بازپرداخت یک پرداخت، یا باطل کردن یک فاکتور. این عملیات‌های "مخرب" سیستم را به حالت قبلی بازمی‌گردانند. اما از دیدگاه تجاری، شما واقعاً در حال حذف داده نیستید. 💼

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

نکات کلیدی (Takeaway) 📌

حذف نرم یک شبکه ایمنی ارزشمند برای بازیابی اطلاعات ارائه می‌دهد و می‌تواند ردیابی داده‌های تاریخی را بهبود بخشد.

با این حال، ارزیابی اینکه آیا این روش واقعاً با نیازمندی‌های خاص برنامه شما همخوانی دارد، بسیار مهم است. عواملی مانند اهمیت بازیابی داده‌های حذف شده، نیازهای ممیزی (auditing) و مقررات صنعت خود را در نظر بگیرید. ایجاد یک ایندکس فیلتر شده می‌تواند عملکرد کوئری را در جداول دارای رکوردهای حذف نرم شده بهبود بخشد.
اگر تصمیم گرفتید که حذف نرم برای شما مناسب است، EF Core ابزارهای لازم را برای یک پیاده‌سازی روان و ساده فراهم می‌کند.

🔖 هشتگ‌ها:
#EntityFrameworkCore #EFCore #SoftDelete #Database #DataPersistence #SQL

⚔️ SQL vs NoSQL

SQL (پایگاه‌داده رابطه‌ای)

🗂 مدل داده: ساخت‌یافته و جدولی

📈 مقیاس‌پذیری: عمودی (Vertical Scaling)

🏗 ساختار (Schema): از قبل تعریف‌شده

✅ پشتیبانی ACID: قوی

🎯 مناسب برای: برنامه‌های تراکنشی

💻 نمونه‌ها: MySQL، PostgreSQL، Oracle

NoSQL (پایگاه‌داده غیررابطه‌ای)

🗂 مدل داده: انعطاف‌پذیر (سند، کلید-مقدار، گراف)

📈 مقیاس‌پذیری: افقی (Horizontal Scaling)

🏗 ساختار (Schema): پویا و بدون ساختار ثابت

✅ پشتیبانی ACID: محدود یا سازگاری تدریجی (Eventual Consistency)

🎯 مناسب برای: داده‌های حجیم (Big Data)، تحلیل‌های لحظه‌ای

💻 نمونه‌ها: MongoDB، Cassandra، Redis

🗂 پایگاه‌داده‌های محبوب NoSQL و کاربرد آن‌ها

MongoDB (مبتنی بر سند) → مدیریت محتوا، کاتالوگ محصولات

Redis (کلید-مقدار) → کشینگ، تحلیل‌های لحظه‌ای، ذخیره‌سازی نشست‌ها

Cassandra (مبتنی بر ستون‌ها) → داده‌های حجیم، سیستم‌های با دسترسی بالا

Neo4j (گراف) → شناسایی تقلب، شبکه‌های اجتماعی

💡 کاربردهای NoSQL

📊 برنامه‌های Big Data: ذخیره و پردازش مؤثر حجم‌های بسیار زیاد داده‌های غیرساخت‌یافته و نیمه‌ساخت‌یافته

⏱️ تحلیل‌های لحظه‌ای (Real-Time Analytics): پشتیبانی از کوئری‌های سریع و تحلیل داده برای موتورهای پیشنهاددهنده یا شناسایی تقلب

🌐 برنامه‌های وب مقیاس‌پذیر: مدیریت کاربران زیاد و ترافیک بالا با مقیاس‌پذیری افقی در بین سرورها

🔄 ذخیره‌سازی داده انعطاف‌پذیر: مدیریت فرمت‌های مختلف داده (JSON، کلید-مقدار، اسناد، گراف) بدون نیاز به ساختار سخت و ثابت

🔖هشتگ‌ها:
#NoSQL #SQL #Database #DatabaseDesign

Entity Framework Extensions 💎

آیا می‌توانیم بهتر از SqlBulkCopy عمل کنیم؟
شاید، حداقل نتایج بنچمارک من نشان می‌دهد که می‌توانیم.

یک کتابخانهٔ فوق‌العاده دیگر به نام Entity Framework Extensions وجود دارد. این فقط یک کتابخانهٔ bulk insert نیست - بنابراین توصیه می‌کنم حتماً بررسی شود. با این حال، امروز آن را برای bulk insert استفاده خواهیم کرد.

برای استفادهٔ ما، متد BulkInsertOptimizedAsync گزینهٔ عالی است. می‌توانیم کالکشن آبجکت‌ها را ارسال کنیم و یک SQL bulk insert انجام خواهد شد. همچنین برخی بهینه‌سازی‌ها زیر هود انجام می‌دهد تا عملکرد بهتر شود.

using var context = new ApplicationDbContext();

await context.BulkInsertOptimizedAsync(GetUsers());

عملکرد آن فوق‌العاده است: ⚡️🔥

EF Core - Entity Framework Extensions، برای ۱۰۰ کاربر: ۱.۸۶ ms
EF Core - Entity Framework Extensions، برای ۱,۰۰۰ کاربر: ۶.۹ ms
EF Core - Entity Framework Extensions، برای ۱۰,۰۰۰ کاربر: ۶۶ ms
EF Core - Entity Framework Extensions، برای ۱۰۰,۰۰۰ کاربر: ۶۳۶ ms
EF Core - Entity Framework Extensions، برای ۱,۰۰۰,۰۰۰ کاربر: ۷,۱۰۶ ms

جمع‌بندی 🎯

کار SqlBulkCopy برای حداکثر سرعت و سادگی بهترین است. 👑
با این حال، Entity Framework Extensions عملکرد فوق‌العاده‌ای ارائه می‌دهند و هم‌زمان سهولت استفاده‌ای که EF Core دارد را حفظ می‌کنند. 💎⚡️

بهترین گزینه به نیازهای خاص پروژهٔ شما بستگی دارد:
فقط عملکرد مهم است؟ SqlBulkCopy راه حل شماست. 🔥

به سرعت عالی و توسعهٔ آسان نیاز دارید؟ EF Core انتخاب هوشمندانه است. ⚡️

به دنبال تعادل بین عملکرد و سهولت استفاده هستید؟ Entity Framework Extensions ⚖️

تصمیم با شماست که بهترین گزینه برای پروژهٔ خودتان کدام است.

امیدوارم مفید بوده باشد. 🙌

🔖هشتگ‌ها:
#EFCore #Dapper #SqlBulkCopy #BulkExtensions #EntityFrameworkExtensions #Performance #CSharp #Database #DotNet #Programming #BulkInsert