دیتابیس چیست؟ راهنمای کامل پایگاه داده به زبان ساده با جدول انتخاب

دیتابیس چیست؟ تعریف بدون اصطلاح

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

یک مثال روزمره: در یک فروشگاه اینترنتی، هر سفارش باید هم زمان با چند چیز گره بخورد: مشتری، محصول، مبلغ، وضعیت پرداخت و آدرس ارسال. اگر این ها در یک فایل متنی باشند، پیدا کردن «سفارش های پرداخت نشدهٔ دو هفتهٔ گذشته» کار یک روز است. در دیتابیس، همان پرسش در چند هزارم ثانیه جواب می گیرد.

این نوشته برای دو گروه است: کسی که می خواهد نقش دیتابیس در کسب و کارش را بداند و کسی که تازه وارد برنامه نویسی شده است. در پایان، جدول تصمیم و پنج پرسش پیش از انتخاب را می بینید.

تفاوت دیتابیس با فایل اکسل و صفحهٔ گسترده

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

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

دیتابیس از داخل چطور کار می کند؟

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

• کلید اصلی: شناسهٔ یکتای هر سطر. بدون آن، دو رکورد شبیه هم قابل تفکیک نیستند.
• کلید بیرونی: ستونی که یک رکورد را به رکورد جدول دیگر وصل می کند (مشتری در جدول سفارش ها).
• پرس وجو: جمله ای که با آن از دیتابیس می پرسیم چه می خواهیم.

کد زیر یک نمونهٔ ساده از زبان پرس وجو است (که در همهٔ دیتابیس های رابطه ای شبیه است):

SELECT customer, amount, created_at
FROM orders
WHERE city = 'شیراز' AND amount > 5000000
ORDER BY amount DESC
LIMIT 20;

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

دیتابیس کنار جدول ها یک ساختار پنهان هم دارد: «ایندکس». در بخش بعد اثر آن را با عدد واقعی می بینیم.

ایندکس چیست و چرا سرعت را جابه جا می کند؟

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

و یک نکتهٔ مهم تر که در همان سنجش بیرون آمد: ایندکس تنها معجزه نمی کند. در یکی از حالت ها، ایندکسی که روی «شهر» ساخته بودیم هیچ بهبودی نداد (۱۰٫۹ در برابر ۱۱٫۲ هزارم ثانیه)، چون ترتیب خواسته شده روی ستون دیگری بود و دیتابیس باز هم مجبور می شد مرتب سازی کند. راه درست، ایندکسی است که «شکل پرس وجو را دنبال کند» — در آن حالت با ایندکس مرکب، زمان از ۱۰٫۹ به حدود صفر رسید.

ترجمهٔ کسب و کاری اش: کندی سایت یا سامانه، در بیشتر مواقع از سرور و هاست نیست؛ از پرس وجوهایی است که ایندکس مناسب ندارند (ترتیب درست کار برای افزایش سرعت سایت). اگر سامانه ای دارید که با گذشت زمان کند شده، پیش از هزینهٔ سخت افزار، وضعیت ایندکس ها را بسنجید.

انواع دیتابیس: کدام برای چه کاری

دیتابیس ها یک نوع نیستند. هر خانواده برای یک شکل از داده ساخته شده و انتخاب اشتباه، هزینهٔ بازنویسی دارد:

• رابطه ای (جدولی): داده های ساختارمند با رابطه های روشن. ستون فقرات بیشتر سامانه های اداری و فروشگاهی. نمونه ها: MySQL، PostgreSQL، SQL Server.
• سندی (غیررابطه ای): داده های بی قاعده یا در حال تغییر؛ هر رکورد می تواند ساختار خودش را داشته باشد. نمونه: MongoDB.
• کلید و مقدار: ذخیره و خواندن بسیار سریع با یک شناسه. برای نشست کاربر و حافظهٔ موقت.
• گرافی: وقتی مهم ترین چیز، رابطه بین موجودیت هاست (شبکهٔ دوستان، مسیرها، توصیه گر).
• سری زمانی: برای داده های پیوسته با مهر زمان؛ سنسورها، آمار مصرف، مانیتورینگ.
• درون حافظه: داده در رم نگه داشته می شود، برای نرخ پاسخ بسیار بالا و صف کارها.

جدول تصمیم: کدام دیتابیس برای کدام پروژه

این جدول را از تجربهٔ پروژه های واقعی نوشتم؛ به جای بحث نظری، از پروژه به انتخاب می رسد:

قاعدهٔ سادهٔ ما در پروژه ها: تا وقتی تراکنش و رابطهٔ دقیق دارید، سراغ رابطه ای بروید؛ انعطاف ساختار را می توان با طراحی درست هم به دست آورد، اما درستی مالی را نمی شود قربانی کرد.

سایت شما کدام دیتابیس را دارد و از کجا بفهمید

این بخش را می توانید خودتان انجام بدهید و نتیجه اش یک عدد و یک نام است. سه راه ساده وجود دارد که به ترتیب از ساده به دقیق چیده شده اند.

راه اول، پنل هاست است: بخش دیتابیس ها فهرست پایگاه داده های سایت را با نام و حجم نشان می دهد.

راه دوم، فایل تنظیمات سایت است که در ریشه نصب قرار دارد و چهار خط اولش می گوید سایت از کدام دیتابیس و کدام کاربر استفاده می کند. کد زیر را در فایل تنظیمات ببینید و نام دیتابیس خود را یادداشت کنید:

define( 'DB_NAME', 'your_site_db' );
define( 'DB_USER', 'your_db_user' );
define( 'DB_PASSWORD', 'your_db_pass' );
define( 'DB_HOST', 'localhost' );

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

SELECT table_name,
  ROUND(data_length/1024/1024, 1) AS mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY data_length DESC;

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

دیتابیس سایت و دیتابیس وردپرس در عمل

وردپرس از همان خانواده رابطه ای استفاده می کند و برای هر سایت یک دیتابیس می سازد. جدول های آن پیشوند یکسان دارند و هر افزونه می تواند جدول تازه بسازد. ولی یک نکته را باید بدانید: همه چیز در وردپرس، از تنظیمات سایت تا کاربران و سفارش های ووکامرس، در همین یک دیتابیس است.

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

چه زمانی به دیتابیس نیازی نیست

این بخش را در هیچ مقالهٔ رقیبی ندیدم، ولی در پروژه ها زیاد به کار می آید. برای همه چیز دیتابیس لازم نیست:

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

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

پنج پرسش پیش از انتخاب دیتابیس

این پنج پرسش را در پروژه های خودمان به عنوان معیار پذیرش به کار می بریم؛ اگر جواب یکی از آن ها روشن نباشد، انتخاب دیتابیس زود است:

1. حجم و رشد: امروز چند رکورد داریم و سال بعد چند تا؟
2. شکل پرس وجوها: بیشتر جستجو می کنیم یا بیشتر ثبت؟ سنگین ترین پرس وجوی روزانه چیست؟
3. هم زمانی: چند کاربر هم زمان داده را تغییر می دهند و اگر دو نفر با هم بنویسند باید چه شود؟
4. درستی در برابر دسترس پذیری: اگر یک لحظه داده در دسترس نباشد چه خسارتی دارد و اگر یک رکورد غلط ثبت شود چه؟
5. نگهداری: چه کسی پشتیبان می گیرد، بازیابی را تمرین می کند و نسخه را به روز می کند؟

جواب همین پنج پرسش، در بیشتر پروژه ها انتخاب را از «فلان دیتابیس مد روز است» به «این دیتابیس برای این شکل کار درست است» می رساند.

تراکنش: چرا دیتابیس رابطه ای برای پول امن تر است

فرض کنید مشتری روی دکمهٔ پرداخت می زند. در همان لحظه سه کار باید انجام شود: مبلغ از حساب کم شود، سفارش ثبت شود و موجودی انبار یکی کم شود. اگر بین این سه کار، برق سرور قطع شود چه اتفاقی می افتد؟ در فایلی که خودمان مدیریت می کنیم، ممکن است پول کم شده باشد ولی سفارش ثبت نشده باشد. دیتابیس رابطه ای برای همین لحظه ها ساخته شده است.

«تراکنش» یعنی بسته ای از چند تغییر که یا همه شان انجام می شود یا هیچ کدام. چهار ویژگی که پشت این تضمین است، در کتاب ها با چهار حرف لاتین شناخته می شود و به زبان ساده این است:

همین چهار مورد است که باعث می شود برای سفارش، پرداخت، انبار و پروندهٔ مالی، دیتابیس رابطه ای انتخاب متعارف باشد؛ نه چون مد روز است، چون مسئله را دقیقا حل می کند.

کدام داده کجا بنشیند: دیتابیس، فایل یا حافظهٔ موقت

یکی از اشتباه های رایج در سامانه های تازه، ریختن همه چیز در دیتابیس است. سه جای متفاوت برای نگهداری داده داریم و هر کدام کار خودش را دارد:

• دیتابیس: داده ای که باید بماند، قابل جستجو باشد و درست بودنش مهم است (سفارش، کاربر، فاکتور).
• حافظهٔ موقت: داده ای که سرعتش مهم است و از دست رفتنش فاجعه نیست (نتیجهٔ جستجوی پرتکرار، نشست کاربر، شمارش بازدید).
• فایل: دادهٔ سنگین و کم تغییر (تصویر، ویدیو، فایل های بارگذاری شده). نگهداری فایل در دیتابیس، پشتیبان گیری را کند و سنگین می کند.

در پروژه های خودمان قاعده این است: هر چیزی که «باید بماند» در دیتابیس، هر چیزی که «فقط سرعت می خواهد» در حافظهٔ موقت، و فایل ها در فضای ذخیره سازی. رعایت همین سه خط، تفاوت بین سامانه ای است که با رشد داده سنگین می شود و سامانه ای که سال ها سبک می ماند.

هزینهٔ نگهداری و انتخاب میزبانی

هزینهٔ دیتابیس فقط اشتراک ماهانه نیست؛ سه قلم دیگر هم هست که در تصمیم اثر دارد:

• حجم و رشد: پشتیبان و فضای دیسک با رشد داده بزرگ می شود؛ دیتابیسی که شش ماه پیش کوچک بود، ممکن است سال بعد پشتیبانش چند برابر شود.
• مهارت نگهداری: نگهداری دیتابیس روی سرور خودتان، کار دوره ای می خواهد: پشتیبان، به روزرسانی امنیتی، بررسی کندی پرس وجوها.
• هزینهٔ قطعی: زیان از کار افتادن دیتابیس معمولا از اشتراک ماهانه بیشتر است؛ پس تضمین دسترس پذیری مهم تر از اختلاف قیمت است.

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

امنیت و پشتیبان گیری

دو موضوعی که تا وقتی حادثه نیفتاده، کسی سراغشان نمی رود و بعد از حادثه، گران ترین موضوع پروژه می شوند:

• دسترسی حداقلی: کاربر دیتابیس برنامه نباید دسترسی ساخت و حذف جدول داشته باشد. هر سرویس، کاربر خودش را بخواهد.
• ورودی های کاربر را پرس وجو نکنید: ساختن پرس وجو با چسباندن متن ورودی، همان حفره ای است که در اخبار به نام تزریق پرس وجو می شناسید. همیشه پارامتر بفرستید.
• پشتیبان روزانه و آزمایش بازیابی: پشتیبانی که یک بار آزمایش بازیابی نشده باشد، پشتیبان نیست؛ یک فایل خوشبینانه است.
• رمزها و اطلاعات حساس: رمز عبور کاربران باید هش شده ذخیره شود، نه خوانا.

در سامانه هایی که با لاراول می سازیم، مهاجرت ها ساختار دیتابیس را نسخه بندی می کنند و بازگردانی هر مرحله ممکن است؛ کار روزمرهٔ خواندن و نوشتن هم با الکوئنت در لاراول انجام می شود که همان زبان پرس وجو را پشت یک واسطهٔ خوانا می آورد.

امنیت دیتابیس؛ چهار کار ساده که واقعا اثر دارد

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

سه کار دیگر هم اثر بزرگی دارند: ساختن کاربر جدا برای هر پایگاه داده، بستن دسترسی از راه دور به جز آدرس سرور، و به روز نگه داشتن نسخه دیتابیس و افزونه ها. برای وردپرس، راهنمای امنیت وردپرس همین کارها را گام به گام توضیح داده است.

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

curl -sI https://example.com/database.sql
curl -sI https://example.com/backup.sql

در آزمون امروز روی سایت خودمان، هر دو نشانی و همچنین نشانی های معروف دیگر مثل فایل تنظیمات و پوشه مدیریت دیتابیس، پاسخ چهارصد و چهار برگرداندند؛ یعنی هیچ کدام از این فایل ها از بیرون قابل خواندن نیست. این نتیجه را هر چند ماه یک بار بسنجید، چون با هر انتقال هاست تغییر می کند.

پشتیبان گیری را خودتان انجام بدهید یا سفارش بدهید؟

این جدول تصمیم را بر اساس کار واقعی نوشته ایم، نه حدس:

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

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

چه کاری در دامنهٔ کار ما نیست

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

پرسش های متداول

دیتابیس چیست به زبان ساده؟ جایی منظم برای نگهداری اطلاعات یک سامانه که می توان آن ها را سریع پیدا کرد، تغییر داد و به هم وصل کرد.

تفاوت دیتابیس و سرور چیست؟ سرور ماشین و محیط اجراست؛ دیتابیس یکی از سرویس هایی است که روی سرور اجرا می شود. یک سرور می تواند چند دیتابیس داشته باشد.

برای یک فروشگاه اینترنتی کوچک کدام دیتابیس مناسب است؟ به شکل کار بستگی دارد. اگر با وردپرس و ووکامرس بسازیم، MySQL انتخاب متعارف است؛ اگر سامانهٔ اختصاصی باشد، PostgreSQL یا MySQL بسته به حجم و نوع گزارش ها انتخاب می شود. خودِ SQL داده‌ای ذخیره نمی‌کند؛ فقط دستور می‌دهد و موتور پایگاه داده آن را اجرا می‌کند.

آیا بدون دیتابیس هم می شود سامانه ساخت؟ بله. بعضی سامانه ها داده را در فایل نگه می دارند و برای حجم کم بسیار هم خوب کار می کنند؛ مرز این کار را در بخش «چه زمانی به دیتابیس نیازی نیست» گفتیم.

دیتابیس ابری با دیتابیس روی سرور خودمان چه تفاوتی دارد؟ در دیتابیس ابری، نگهداری، پشتیبان و مقیاس پذیری با سرویس دهنده است و شما بابتش اشتراک می دهید؛ در سرور خودتان کنترل بیشتر است و مسئولیت نگهداری هم با شماست.

چرا سامانه ما بعد از مدتی کند شده است؟ در بیشتر موارد سه علت دارد: نبود ایندکس مناسب روی پرس وجوهای پرتکرار، رشد داده بدون پاکسازی، و پرس وجوهای سنگینی که در هر بازدید اجرا می شوند. سنجش گام به گام این سه، پیش از هر هزینهٔ سخت افزاری، جواب می دهد.

جمع بندی

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