پایگاه داده و SQL مقدماتی

چرا یک فایل متنی کافی نیست؟

می شود اطلاعات کاربران را در یک فایل متنی نگه داشت و برای صد ردیف هم خوب کار می کند. سه چیز آن را می شکند و هر سه در همان ماه اول پیش می آیند.

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

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

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

جدول، سطر، ستون و آن ستون id

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

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

حالا یک مثال واقعی که فرض ذهنی رایج را خراب می کند. جدول اصلی همین سایت که وردپرس به آن posts می گوید، روزی که این درس بررسی شد ۷۸۴ سطر داشت، ولی این ۷۸۴ سطر ۲۴ نوع مختلف چیز بودند: ۲۶۳ نوشته بلاگ، ۲۴۰ فایل رسانه، ۳۷ برگه، و بقیه پروژه و پیام و آگهی و چند چیز دیگر.

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

سه دستوری که بیشتر کارها با آنها انجام می شود

SQL زبان درخواست است، نه زبان دستور دادن قدم به قدم. شما نمی گویید چطور بگرد؛ می گویید چه چیزی می خواهم، و پایگاه داده خودش راه رسیدن را انتخاب می کند.

SELECT name, email FROM users WHERE city = 'تهران';

INSERT INTO users (name, email, city) VALUES ('مریم', 'm@example.com', 'شیراز');

UPDATE users SET city = 'اصفهان' WHERE id = 42;

سه چیز در همین سه خط هست که ارزش دیدن دارد. SELECT می گوید کدام ستون ها، FROM می گوید از کدام جدول و WHERE می گوید کدام سطرها. اگر ستون ها را ندانید SELECT * همه را می آورد، که برای نگاه کردن خوب است و در کد برنامه عادت بدی است، چون روزی که یک ستون اضافه شود برنامه شما چیزی می گیرد که انتظارش را نداشته.

خطرناک ترین کلمه این صفحه هم همان WHERE است، به خاطر نبودنش. UPDATE users SET city = 'اصفهان'; یک خطای نحوی نیست؛ کاملا معتبر است و شهر همه کاربران را عوض می کند. مستندات هر دو موتور MySQL و MariaDB این را صریح نوشته اند و حتی حالتی دارند که چنین دستوری را رد می کند.

عادتی که این را حل می کند یک خط بیشتر تایپ کردن است: هر UPDATE یا DELETE را اول به شکل SELECT با همان شرط بنویسید و ببینید چند سطر برمی گردد. اگر عدد آن چیزی نبود که فکر می کردید، شرط شما اشتباه است و تازه فهمیدید، نه بعد از اینکه داده ها رفته باشند.

پایگاه داده و کش را با هم اشتباه نگیرید

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

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

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

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

کوئری امن یعنی چه؟

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

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

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