نوشتن کوئری SQL برای کسی که SQL بلد نیست

گزارش فروش را باید از تیم فنی بخواهید و سه روز بعد برسد. اگر به دیتابیس دسترسی خواندن دارید، می‌شود این چرخه را کوتاه کرد — با چند احتیاط جدی.

🍊 تیم نارنگی ⏱ 5 دقیقه مطالعه
نمایش یک کوئری SQL و جدول خروجی آن روی صفحه‌ی کامپیوتر

مدیر فروشگاه می‌خواهد بداند در سه ماه گذشته کدام دسته‌بندی محصول بیشترین سفارش لغوشده را داشته. داده در دیتابیس هست. دسترسی خواندن هم دارد. ولی برای گرفتن این عدد باید تیکت بزند، منتظر بماند، و احتمالاً بار اول چیزی بگیرد که دقیقاً سؤالش نبوده.

نوشتن کوئری SQL با کمک هوش مصنوعی این چرخه را کوتاه می‌کند. نه به این معنی که دیگر لازم نیست چیزی بدانید — به این معنی که به‌جای یادگرفتن نحو زبان، باید یاد بگیرید سؤال را درست بپرسید و جواب را چک کنید.

اول ساختار، بعد سؤال

بزرگ‌ترین دلیل کوئری‌های غلط این است که مدل نمی‌داند جدول‌های شما چه شکلی‌اند. اگر فقط بپرسید «کوئری فروش سه ماه اخیر را بنویس»، جدولی به اسم sales فرض می‌کند که وجود ندارد.

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

دیتابیس: MySQL 8

جدول orders:
  id, user_id, status (paid/canceled/pending),
  total_amount (ریال), created_at (datetime میلادی)
جدول order_items:
  id, order_id, product_id, qty, unit_price
جدول products:
  id, title, category_id
جدول categories:
  id, name

سؤال: در ۹۰ روز گذشته، به تفکیک دسته‌بندی،
چند سفارش لغو شده و مبلغشان چقدر بوده؟
خروجی: دسته‌بندی، تعداد، مجموع مبلغ، مرتب نزولی بر اساس مبلغ.
فقط SELECT بنویس. کوئری را خط‌به‌خط کامنت فارسی بگذار.

آن دو خط آخر را همیشه بنویسید. «فقط SELECT» جلوی خروجی خطرناک را می‌گیرد و کامنت فارسی باعث می‌شود بتوانید بخوانید چه اتفاقی می‌افتد.

⚠️ قاعده‌ی بدون استثنا

اگر برنامه‌نویس نیستید، هیچ‌وقت کوئری‌ای را که با UPDATE، DELETE، DROP، TRUNCATE یا ALTER شروع می‌شود اجرا نکنید — حتی اگر مدل مطمئن باشد و حتی اگر «فقط یک رکورد» باشد. این‌ها را به کسی بدهید که پشتیبان می‌گیرد و مسئولیتش را می‌پذیرد.

خواندن کوئری قبل از اجرا

لازم نیست SQL بنویسید، ولی باید بتوانید چهار چیز را در کوئری پیدا کنید:

چه چیزی را ببینیدیعنی چهچه چیزی خطر دارد
کلمه‌ی اولنوع عملیاتهرچیزی غیر از SELECT
FROM و JOINاز کدام جدول‌ها می‌خواندجدولی که نمی‌شناسید
WHEREچه چیزی فیلتر شدهنبودنش، یا شرط تاریخ اشتباه
GROUP BYبر چه اساسی جمع زدهستونی که منظورتان نبوده
LIMITچند سطر برمی‌گرددنبودنش روی جدول بزرگ

اگر یکی از این‌ها را نفهمیدید، همان‌جا بپرسید «این خط دقیقاً چه کار می‌کند؟». پرسیدن، به‌مراتب ارزان‌تر از اجرای کوئری نامفهوم است.

تاریخ شمسی: تله‌ی اصلی

بیشتر سیستم‌های ایرانی یکی از این دو کار را می‌کنند: تاریخ را میلادی ذخیره می‌کنند و موقع نمایش شمسی می‌کنند، یا مستقیم رشته‌ی شمسی مثل 1404/05/12 نگه می‌دارند. مدل پیش‌فرض حالت اول را فرض می‌کند.

اگر حالت دوم است، صریح بنویسید و یک نمونه‌ی واقعی بدهید: «ستون jdate رشته است به شکل ۱۴۰۴/۰۵/۱۲». بدون این، کوئری اجرا می‌شود، خطا نمی‌دهد، و عددی برمی‌گرداند که به بازه‌ی موردنظرتان ربطی ندارد. این خطرناک‌ترین نوع اشتباه است چون بی‌سروصداست.

راستی‌آزمایی خروجی

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

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

کوئری کند و جدول بزرگ

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

فراتر از گزارش

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

داده‌ی مشتری را جابه‌جا نکنید

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

شروع کنید با یک سؤال کوچک

اولین کوئری‌تان را چیزی انتخاب کنید که جوابش را می‌دانید. ساختار جدول را بدهید، سؤال را بپرسید، خروجی را بخوانید و عدد را با چیزی که در دست دارید بسنجید. همین یک دور، اعتماد درست را می‌سازد — می‌توانید همین حالا در نارنگی امتحانش کنید.

برای مرجع نحو، مستندات SELECT در MySQL و آموزش SQL پستگرس دقیق‌ترین منبع‌اند.

جمع‌بندی

نوشتن کوئری SQL دیگر گلوگاه نیست؛ گلوگاه جدید، اعتماد است. کوئری‌ای که نمی‌فهمید چه می‌کند، همان‌قدر بی‌فایده است که کوئری نداشته باشید — با این تفاوت که عدد اشتباهش را باور می‌کنید.

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

مطالب مرتبط:

پرسش‌های پرتکرار

بدون دانستن SQL می‌توانم از دیتابیس گزارش بگیرم؟ +
برای گزارش‌های خواندنی بله، به شرطی که ساختار جدول‌ها را به مدل بدهید و خروجی را راستی‌آزمایی کنید. چیزی که نمی‌توانید از آن فرار کنید، خواندن کوئری قبل از اجراست؛ لازم نیست بتوانید بنویسید، ولی باید بفهمید چه می‌کند.
خطرناک‌ترین اشتباه چیست؟ +
اجرای کوئری‌های تغییردهنده روی دیتابیس اصلی. یک UPDATE یا DELETE بدون شرط درست، در یک لحظه هزاران رکورد را عوض می‌کند و بازگرداندنش بدون نسخه‌ی پشتیبان ممکن نیست. اگر برنامه‌نویس نیستید، فقط SELECT اجرا کنید.
چرا کوئری‌های مربوط به تاریخ شمسی اشتباه درمی‌آید؟ +
چون مدل پیش‌فرض میلادی فکر می‌کند. اگر تاریخ‌ها را به‌صورت رشته‌ی شمسی ذخیره کرده‌اید، باید صریح بگویید و نمونه‌ی واقعی مقدار را نشان بدهید. وگرنه کوئری‌ای می‌گیرید که از نظر نحوی درست است و بازه‌ی زمانی کاملاً اشتباهی برمی‌گرداند.
چطور بفهمم عددی که گرفته‌ام درست است؟ +
با یک نمونه‌ی کوچک که جوابش را از قبل می‌دانید. مثلاً فروش یک روز مشخص را که در گزارش صندوق دارید بگیرید و مقایسه کنید. اگر خواندید و خواندید و باز مطمئن نشدید، همان یک بار از یک نفر فنی بپرسید.
ساختار جدول‌های شرکت را دادن به مدل مشکل امنیتی ندارد؟ +
نام جدول و ستون معمولاً حساس نیست، ولی داده‌ی واقعی مشتریان حساس است. ساختار را بدهید، نمونه‌ی داده را ساختگی بسازید و سیاست داخلی شرکتتان را هم چک کنید — در بعضی سازمان‌ها همین ساختار هم محرمانه حساب می‌شود.
#نوشتن کوئری SQL #اس کیو ال #گزارش‌گیری از دیتابیس #دیتابیس #تحلیل فروش
به‌دردِ کسی می‌خورد؟ تلگرام واتساپ
🍊

خواندنش خوب بود — حالا امتحانش کن

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

بدونِ نصب هم کار می‌کند — ولی در اپ سریع‌تر است