اهمیت دیتابیس در برنامه‌نویسی؛ چرا CRUD کافی نیست؟

وقتی کاربر یک دوره می‌خرد، سامانه باید بداند خریدار چه کسی است، کدام دوره را خریده، نتیجهٔ پرداخت چیست و آیا دسترسی باید فعال شود. اگر این واقعیت‌ها در چند جای نامرتبط ذخیره شوند، ممکن است پول دریافت شود اما دسترسی ساخته نشود، یا دسترسی دوبار صادر شود.

طراحی دیتابیس کمک می‌کند معنای داده روشن بماند. رابطه‌ها، محدودیت‌ها و تراکنش‌ها فقط موضوعات تئوری نیستند؛ قراردادهایی هستند که از تغییر ناسازگار اطلاعات جلوگیری می‌کنند. حتی اگر تمام کوئری‌ها را ORM تولید کند، تصمیم دربارهٔ این قراردادها همچنان با شماست.

CREATE TABLE enrollments (
  user_id BIGINT NOT NULL,
  course_id BIGINT NOT NULL,
  created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (user_id, course_id),
  FOREIGN KEY (user_id) REFERENCES users(id),
  FOREIGN KEY (course_id) REFERENCES courses(id)
);

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

ایندکس پاسخ همهٔ مشکلات سرعت نیست. اول باید کوئری‌های پرتکرار، اندازهٔ داده و الگوی نوشتن را بشناسید. محدودیت همزمانی هم با اضافه کردن یک ستون وضعیت حل نمی‌شود؛ باید بررسی کنید دو درخواست همزمان چه چیزی می‌خوانند و چه چیزی تغییر می‌دهند.

یک سامانهٔ کتابخانه بسازید: کاربر، کتاب و امانت را جدا مدل کنید. سپس توضیح دهید چرا عنوان کتاب نباید در همهٔ ردیف‌های امانت تکرار شود. محدودیت امانت فعال را مشخص کنید و سناریوی دو درخواست همزمان را بررسی کنید. برای گزارش دیرکرد، کوئری بنویسید و با دادهٔ بیشتر نقشهٔ اجرای آن را ببینید.

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