ERD متنی

جدول	کلید	رابطه
Customer	CustomerID	یک به چند با Order
Order	OrderID	یک به چند با OrderLine و Payment
Product	ProductID	یک به چند با OrderLine
OrderLine	OrderID + LineNo	پل Order و Product

۲۲ پرسش واقعی برای توسعه

فروش روزانه
فروش ماهانه
پرفروش‌ترین محصول
کم‌فروش‌ترین محصول
مشتریان غیرفعال
ارزش طول عمر مشتری
میانگین سبد
نرخ بازگشت
سفارش‌های ناقص
موجودی بحرانی
گردش موجودی
فروشنده برتر
رشد سالانه
رشد ماهانه
سهم دسته محصول
تخفیف موثر
پرداخت معوق
زمان ارسال
خرید تکراری
هم‌بستگی محصول
پیش‌بینی ساده تقاضا
کنترل مغایرت مالی

این فصل طراحی ERD مشتری، سفارش، محصول و پرداخت را از دید یک متخصص SQL Server بررسی می‌کند. هدف فقط حفظ کردن Syntax نیست؛ باید بدانیم موتور پایگاه داده چگونه تصمیم می‌گیرد، داده چگونه نگهداری می‌شود و هر انتخاب چه اثری بر صحت، امنیت و کارایی دارد. هنگام مطالعه، مثال‌ها را در یک Database آزمایشی اجرا کنید، Actual Execution Plan و پیام‌های خطا را بخوانید و نتیجه را با انتظار خود مقایسه کنید. این عادت ساده فاصله میان دانستن دستورها و توانایی حل مسئله واقعی را کم می‌کند.

موضوع اول، طراحی ERD مشتری، سفارش، محصول و پرداخت، پایه تصمیم‌های بعدی است. در محیط Production هیچ دستور مهمی را بدون شناخت تعداد ردیف، نوع داده، Constraintها، Indexها و سطح دسترسی اجرا نکنید. ابتدا با یک SELECT محدود دامنه را بسنجید، سپس تغییر را داخل Transaction انجام دهید و برای عملیات حساس راه بازگشت داشته باشید. همچنین رفتار نسخه و Compatibility Level را بررسی کنید؛ قابلیتی که در SQL Server 2022 وجود دارد ممکن است در Database با سطح سازگاری قدیمی فعال نباشد.

داده نمونه و محدودیت‌ها

داده نمونه و محدودیت‌ها زمانی ارزشمند است که با نیاز کسب‌وکار پیوند بخورد. برای نمونه، یک سامانه فروش به پاسخ درست، زمان پاسخ قابل پیش‌بینی و Audit قابل اعتماد نیاز دارد. طراحی باید برای رشد داده، اجرای همزمان چند کاربر و بازیابی پس از خطا آماده باشد. اندازه‌گیری با SET STATISTICS IO, TIME ON، Query Store و Execution Plan بهتر از حدس است. هر بهینه‌سازی را با داده‌ای شبیه Production آزمایش کنید، زیرا یک کوئری روی هزار ردیف می‌تواند عالی و روی صد میلیون ردیف نامناسب باشد.

💡 نکته حرفه‌ای

برای داده نمونه و محدودیت‌ها یک معیار قابل اندازه‌گیری تعریف کنید: Logical Read، CPU، مدت اجرا، تعداد ردیف تخمینی و واقعی، یا میزان Blocking. تغییر بدون Baseline ممکن است فقط هزینه را از یک بخش به بخش دیگر منتقل کند.

بیش از بیست الگوی کوئری عملی

در بحث بیش از بیست الگوی کوئری عملی، خوانایی و قابلیت نگهداری هم‌ارز سرعت‌اند. نام‌گذاری روشن، Schema مشخص، Alias معنادار و Comment کوتاه باعث می‌شود نفر بعدی قصد کد را بفهمد. از SELECT * در قراردادهای پایدار برنامه پرهیز کنید، نوع داده پارامتر را با ستون هماهنگ نگه دارید و تبدیل ضمنی را جدی بگیرید. تبدیل روی سمت ستون می‌تواند Index Seek را به Scan تبدیل کند و مصرف CPU و I/O را چند برابر سازد.

Optimizer بر اساس آمار و مدل هزینه Plan می‌سازد، نه بر اساس نیت برنامه‌نویس. بنابراین آمار کهنه، توزیع نامتوازن داده، Parameter Sniffing یا Predicate غیر SARGable می‌تواند Plan ضعیف تولید کند. راه‌حل حرفه‌ای همیشه افزودن Hint نیست؛ نخست علت را با Actual Plan، Runtime Statistics و Waitها پیدا کنید. سپس کم‌خطرترین تغییر را انتخاب و اثر آن را در چند شکل پارامتر بسنجید.

⚠️ اشتباه رایج

اجرای مستقیم مثال‌ها روی Production، استفاده از حساب sysadmin برای برنامه، یا افزودن Index بدون بررسی هزینه نوشتن. نسخه آزمایشی، Backup معتبر و اصل Least Privilege بخشی از خود راه‌حل هستند.

گزارش فروش، موجودی و مشتری

گزارش فروش، موجودی و مشتری حلقه اتصال این فصل به معماری کل سامانه است. تصمیم Database باید همراه با الگوی تراکنش برنامه، SLA، سیاست Backup، امنیت و مشاهده‌پذیری بررسی شود. برای مثال، افزایش Isolation ممکن است صحت خواندن را بهتر کند اما Blocking را افزایش دهد؛ یک Index پوششی خواندن را سریع می‌کند اما فضای ذخیره‌سازی و هزینه INSERT را بالا می‌برد. پاسخ درست وابسته به بارکاری است و باید مستند شود.

بهترین Practice این است که تغییر را کوچک، قابل تکرار و قابل بازگشت نگه دارید. Script را در Source Control قرار دهید، قبل و بعد از اجرا معیار ثبت کنید، روی داده حساس Masking به‌کار ببرید و مجوز را فقط به عملیات لازم محدود کنید. برای جزئیات رسمی Syntax و تفاوت نسخه‌ها Microsoft Learn مرجع اصلی است؛ برای تفکر مجموعه‌ای و Window Functionها، کتاب‌های Itzik Ben-Gan مکمل بسیار خوبی هستند.

✅ چک‌لیست عملی

هدف را تعریف کنید؛ داده و Plan پایه را ثبت کنید؛ مثال را در محیط امن اجرا کنید؛ صحت نتیجه را با Edge Case و NULL بسنجید؛ اثر همزمانی و امنیت را بررسی کنید؛ و نتیجه را مستند سازید.

🎯 تمرین

یک Database آزمایشی با حداقل صد هزار ردیف بسازید و نمونه این صفحه را اجرا کنید. سپس یک تغییر منطقی—مانند Index، بازنویسی Predicate یا تغییر نوع داده—اعمال کنید. Logical Read، مدت اجرا و Plan را پیش و پس از تغییر ثبت کنید. توضیح دهید چرا نتیجه بهتر یا بدتر شد و چه خطری برای محیط Production باقی می‌ماند. برای تکمیل تصویر، به فصل‌های معماری، Index، Transaction و Execution Plan در همین کتاب مراجعه کنید.

نمونه قابل اجرا

-- Run in a test database
SELECT TOP (20) p.ProductID,p.Name,SUM(ol.Quantity) AS Units,SUM(ol.Quantity*ol.UnitPrice) AS Revenue
FROM Sales.OrderLine ol JOIN Production.Product p ON p.ProductID=ol.ProductID
JOIN Sales.Orders o ON o.OrderID=ol.OrderID
WHERE o.OrderDate>=DATEADD(day,-90,SYSDATETIME())
GROUP BY p.ProductID,p.Name ORDER BY Revenue DESC;