نوشتن کوئری SQL برای کسی که 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 اجرا کنید، و هر عدد را با چیزی که مستقل از دیتابیس میدانید بسنجید. با همین دو، بیشتر گزارشهای روزمره را خودتان میگیرید.
مطالب مرتبط: