نوشتن SQL با هوش مصنوعی؛ کوئری و تست نمونه

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

چه ورودی‌هایی به مدل بدهیم؟#

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

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

ساخت دیتاست کوچکی که پاسخ آن روشن باشد#

اطلاعات زیر کاملاً فرضی است. بازه گزارش از ابتدای سپتامبر تا ابتدای اکتبر ۲۰۲۶ است و تاریخ‌ها به شکل ISO و در یک مبنای زمانی یکسان ثبت شده‌اند.

CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  city TEXT NOT NULL,
  created_at TEXT NOT NULL,
  status TEXT NOT NULL,
  total_toman INTEGER NOT NULL
);
INSERT INTO orders VALUES
  (1, 'تهران', '2026-09-01', 'paid', 120000),
  (2, 'تهران', '2026-09-20', 'paid', 80000),
  (3, 'شیراز', '2026-09-25', 'cancelled', 90000),
  (4, 'شیراز', '2026-09-30', 'paid', 50000),
  (5, 'تهران', '2026-10-01', 'paid', 70000);

پیش از درخواست SQL، نتیجه را بنویسید: تهران دو سفارش و ۲۰۰ هزار تومان؛ شیراز یک سفارش و ۵۰ هزار تومان. ردیف لغوشده و سفارش اول اکتبر نباید وارد گزارش شوند. داشتن جواب قابل محاسبه، آزمون مدل را از قضاوت ظاهری کد جدا می‌کند.

پرامپت فارسی برای تولید کوئری#

برای SQLite یک SELECT بنویس. ساختار orders در ادامه آمده است و هر ردیف یک سفارش مستقل است. گزارش تعداد سفارش و مجموع total_toman به تفکیک city را فقط برای status برابر paid و تاریخ از 2026-09-01 شامل تا 2026-10-01 خارج می‌خواهم. نام جدول یا ستون تازه نساز. فرض‌های باقی‌مانده را بگو، کوئری را توضیح بده و سه آزمون مرزی پیشنهاد کن. هیچ دستور تغییر داده تولید نکن. سپس خروجی مورد انتظار را از پنج ردیف آموزشی محاسبه کن.

یک پاسخ مناسب برای همین قرارداد چنین است:

SELECT
  city,
  COUNT(*) AS order_count,
  SUM(total_toman) AS revenue_toman
FROM orders
WHERE status = 'paid'
  AND created_at >= '2026-09-01'
  AND created_at < '2026-10-01'
GROUP BY city
ORDER BY revenue_toman DESC, city;

مقایسه متنی تاریخ در این مثال به خاطر قالب یکنواخت ISO کار می‌کند. آن را به تاریخ شمسی متنی، قالب‌های مخلوط یا منطقه‌های زمانی متفاوت تعمیم ندهید. مرزهای واقعی گزارش باید با روش ذخیره‌سازی پروژه هماهنگ باشند. قواعد SELECT را می‌توانید در مستندات رسمی SQLite بررسی کنید.

خطای JOIN چگونه عدد فروش را بزرگ می‌کند؟#

اگر جدول اقلام سفارش را به orders وصل کنید، سفارش دارای سه قلم به سه ردیف تبدیل می‌شود. جمع total_toman بعد از این اتصال، مبلغ همان سفارش را سه بار حساب می‌کند. DISTINCT روی مبلغ نیز راه‌حل عمومی نیست؛ دو سفارش مستقل می‌توانند مبلغ برابر داشته باشند.

از مدل بپرسید: «بعد از هر JOIN، سطح هر ردیف چیست و کلید یکتای نتیجه کدام است؟» اگر فقط برای شرط وجود یک قلم اتصال لازم دارید، استفاده از EXISTS ممکن است مناسب باشد. اگر گزارش قلم می‌خواهید، ابتدا مبلغ قلم و تعریف محاسبه را روشن کنید. انتخاب روش باید از سؤال کسب‌وکار بیاید، نه از کوتاه‌تر بودن کوئری.

آزمون‌هایی که قبل از استفاده لازم‌اند#

کنترل مرز زمانی#

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

کنترل داده خالی و تکراری#

مشخص کنید city خالی چه گروهی می‌سازد و مبلغ NULL چه معنایی دارد. با افزودن دو سفارش با مبلغ یکسان بررسی کنید که هر دو شمرده می‌شوند. اگر جدول تضمین یکتایی ندارد، پیش از گزارش مسئله کیفیت داده را حل کنید؛ COUNT DISTINCT نباید بدون فهم علت، خطای ورودی را پنهان کند.

کنترل هزینه و پارامترها#

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

چگونه پاسخ اشتباه مدل را اصلاح کنیم؟#

به جای «کوئری غلط است»، اختلاف قابل مشاهده بدهید: «انتظار تهران دو سفارش بود؛ سه ردیف برگشته است. جدول اقلام برای سفارش اول دو رکورد دارد.» سپس از مدل بخواهید علت را به رابطه جدول‌ها وصل کند و کمترین تغییر لازم را پیشنهاد دهد. یک تغییر را اجرا کنید و همان دیتاست را دوباره بسنجید.

برای ثبت نتیجه، سؤال نهایی، طرح جدول، کوئری، دیتاست آزمون و خروجی مورد انتظار را کنار هم نگه دارید. این بسته کوچک، گزارش را قابل نگهداری می‌کند. پاکسازی CSV با هوش مصنوعی به آماده‌سازی ورودی کمک می‌کند و نوشتن تست کیس روش ساخت آزمون قابل مشاهده را توضیح می‌دهد. برای تمرین نوشتن پرامپت با طرح ساختگی، از پنل GPT Plus استفاده کنید.