پروژه نهایی StoreDb

Database Design | Constraints | Views | Procedures | Indexes | Security | Backup

StoreDb نهایی مفاهیم کتاب را در یک طراحی یکپارچه جمع می‌کند: Catalog، Customer، Order، Payment، Tag، Index، Procedure، Security و Recovery باید به‌عنوان اجزای یک سیستم واحد سازگار باشند.

متن این فصل با رویکرد مرجع فنی و قابل استفاده در پروژه واقعی تنظیم شده است؛ مثال‌ها در امتداد مدل StoreDb نوشته شده‌اند و اصطلاحات اصلی SQL Server و T-SQL به‌صورت یکدست به‌کار می‌روند.

1. مفاهیم و قراردادهای اصلی

StoreDb نهایی مفاهیم کتاب را در یک طراحی یکپارچه جمع می‌کند: Catalog، Customer، Order، Payment، Tag، Index، Procedure، Security و Recovery باید به‌عنوان اجزای یک سیستم واحد سازگار باشند.

در طراحی پایگاه داده، Syntax تنها بخشی از مسئله است. نوع داده، Constraint، الگوی دسترسی، Transaction و هزینه اجرای Query باید هم‌زمان با نیاز Domain در نظر گرفته شوند.

2. ساختار و Syntax پایه

Database از Schemaهای catalog و sales استفاده می‌کند. Tableها Constraint کامل، Foreign Key و Indexهای متناسب با Query دارند. Procedure ثبت سفارش Transactional و Idempotency-aware طراحی می‌شود.

IF DB_ID(N'StoreDb') IS NULL
    CREATE DATABASE StoreDb;
GO
USE StoreDb;
GO

IF NOT EXISTS (SELECT 1 FROM sys.schemas WHERE name = N'catalog')
    EXEC(N'CREATE SCHEMA catalog');
GO
IF NOT EXISTS (SELECT 1 FROM sys.schemas WHERE name = N'sales')
    EXEC(N'CREATE SCHEMA sales');
GO

3. سناریوی StoreDb

جدول Orders دارای RequestId یکتای اختیاری است تا Retry API سفارش تکراری نسازد. کاهش Stock و ثبت Order در Transaction واحد انجام می‌شوند و Constraintها مانع داده نامعتبر می‌شوند.

نمونه‌های این فصل بر مدل فروشگاهی StoreDb بنا شده‌اند تا ارتباط مفاهیم میان فصل‌ها حفظ شود و Queryها در یک Context یکپارچه قابل بررسی باشند.

CREATE UNIQUE INDEX UX_Orders_RequestId_NotNull
ON sales.Orders(RequestId)
WHERE RequestId IS NOT NULL;
GO

CREATE INDEX IX_Orders_CustomerId_OrderDate
ON sales.Orders(CustomerId, OrderDate DESC)
INCLUDE (Status, TotalAmount);
GO

4. اصول طراحی و Performance

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

• Schema بر اساس Domain سازماندهی شود.
• Idempotency برای Commandهای قابل Retry طراحی شود.
• Procedureهای Write Transaction کوتاه و کنترل‌شده داشته باشند.
• Runtime، Reporting و Migration Permission جدا باشند.

5. خطاهای رایج و نکات ایمنی

دستورهای SQL می‌توانند مستقیماً داده و ساختار را تغییر دهند؛ بنابراین بازبینی Context، تعداد Rowهای هدف و اثر Transaction قبل از اجرای تغییرات اهمیت عملی دارد.

• اجرای Seed یا DDL مخرب روی Production بدون کنترل.
• Procedure ثبت سفارش بدون بررسی Stock Atomic.
• Indexهای زیاد و تکراری.
• Backup Plan بدون Restore Test پس از استقرار.

6. چک‌لیست نهایی فصل

• ساخت Database از صفر با Script نسخه‌بندی‌شده ممکن است.
• Constraint و Relationship کامل هستند.
• Query، View و Procedureهای اصلی تست شده‌اند.
• Index، Security، Backup و Smoke Test پوشش داده شده‌اند.

7. جمع‌بندی

خروجی این فصل باید به تصمیمی قابل اتکا در طراحی یا Query منجر شود؛ صحت داده، قابلیت نگهداری و رفتار Performance سه معیار ثابت برای ارزیابی نمونه‌ها هستند.