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

نوشتن SQL با کمک هوش مصنوعی یکی از پرکاربردترین سناریوهای روزمرهٔ هر کسی است که با داده سروکار دارد: کافی است بخواهید «تعداد سفارش‌های هفتهٔ گذشته به تفکیک شهر را بده» و مدل در چند ثانیه یک کوئری کامل تحویل می‌دهد. این سرعت وسوسه‌انگیز است، اما دقیقاً همین سرعت خطرناک‌ترین بخش ماجراست. یک کوئری SQL که به‌نظر درست می‌آید و کپی-پیست می‌شود، اگر اشتباه باشد، می‌تواند نه یک خطای نرم بلکه از دست رفتن دادهٔ واقعی را رقم بزند. این مقاله دربارهٔ همین فاصلهٔ بین «کوئری درست به‌نظر می‌رسد» و «کوئری واقعاً درست است» صحبت می‌کند.

چرا SQL از خیلی خروجی‌های دیگر AI خطرناک‌تر است

وقتی هوش مصنوعی یک پاراگراف اشتباه می‌نویسد یا یک ترجمهٔ نادرست می‌دهد، معمولاً قابل بازگشت است — دوباره می‌نویسید. اما SQL روی یک دیتابیس زنده اجرا می‌شود و بخشی از دستورات آن — به‌خصوص UPDATE و DELETE — اثر جانبی دائمی روی داده دارند. یک تفاوت کوچک، مثل نبود عبارت WHERE، می‌تواند نتیجهٔ کوئری را از «به‌روزرسانی یک رکورد» به «به‌روزرسانی کل جدول» تغییر دهد.

یک UPDATE یا DELETE بدون WHERE کل جدول را تحت تأثیر قرار می‌دهد — نه یک رکورد را، بلکه همهٔ ردیف‌ها را. این دقیقاً همان چیزی است که باید قبل از اجرای هر کوئری تولیدشده، با چشم خودتان بررسی کنید.

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

-- کوئری درست: فقط سفارش‌های لغوشدهٔ کاربر مشخص را حذف می‌کند
DELETE FROM orders
WHERE customer_id = 4821 AND status = 'cancelled';

-- کوئری خطرناک: همهٔ ردیف‌های جدول orders را حذف می‌کند
DELETE FROM orders;

اگر مدل به هر دلیلی (خلاصه‌سازی نادرست درخواست شما، یا حذف تصادفی یک شرط در بازنویسی) نسخهٔ دوم را تولید کند، ظاهر دستور همچنان «معتبر» و «قابل اجرا» است — هیچ خطای syntax نمی‌دهد. دیتابیس تفاوتی بین «حذف عمدی همه چیز» و «حذف اشتباهی همه چیز» نمی‌بیند.

چرا نمی‌توان فقط به ظاهر کوئری اعتماد کرد

مدل زبانی زبان طبیعی شما را به یک ساختار SQL نگاشت می‌کند، اما این نگاشت گاهی نیت شما را کامل حفظ نمی‌کند. اگر بگویید «سفارش‌های تستی را پاک کن»، مدل ممکن است شرط را بر اساس یک فیلد نادرست بسازد (مثلاً status = 'test' در حالی که فیلد واقعی is_test = true است) و چون هیچ ردیفی با آن شرط مطابقت ندارد، کوئری بدون خطا اجرا و بدون اثر باقی می‌ماند — که خودش گمراه‌کننده است، چون شما فکر می‌کنید کار انجام شده. حالت خطرناک‌تر وقتی است که شرط اشتباه، دقیقاً برعکسِ نیت شما عمل کند و رکوردهای غیرمرتبط را هدف بگیرد.

یک روال ایمن برای اجرای کوئری تولیدشده

SELECT تست، بهترین دوست شماست

یک عادت ساده و بسیار مؤثر: پیش از هر UPDATE یا DELETE، همان شرط WHERE را در یک SELECT اجرا کنید و تعداد و نمونه‌ای از ردیف‌های برگشتی را ببینید.

-- قبل از اجرای UPDATE، اول این را اجرا کنید
SELECT COUNT(*) FROM orders
WHERE customer_id = 4821 AND status = 'cancelled';

-- اگر تعداد منطقی بود (مثلاً ۳، نه ۳۰۰۰۰)، آن‌وقت:
UPDATE orders SET archived = true
WHERE customer_id = 4821 AND status = 'cancelled';

اگر عدد برگشتی از SELECT COUNT(*) با انتظار شما همخوانی نداشت — خیلی کم یا خیلی زیاد بود — این هشدار روشنی است که شرط دقیقاً همان چیزی نیست که فکر می‌کردید، پیش از آن‌که داده‌ای از بین برود.

محدودیت‌های دسترسی، لایهٔ دفاعی دوم

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

برای آشنایی بیشتر با معماری امن‌تر گردش‌کار داده‌محور، نقشهٔ راه هوش مصنوعی و داده و برای نوشتن promptهایی که کوئری‌های قابل‌پیش‌بینی‌تر تولید می‌کنند، نقشهٔ راه مهندسی پرامپت را ببینید.

اشتباهات رایج دیگر در کوئری‌های تولیدشده

خطر فقط در نبود WHERE خلاصه نمی‌شود. یک JOIN نادرست بین دو جدول می‌تواند بدون هیچ خطای اجرایی، تعداد ردیف‌ها را چند برابر کند (مثلاً وقتی رابطهٔ یک‌به‌چند به‌اشتباه به‌عنوان یک‌به‌یک فرض شده) و اعداد گزارش را کاملاً نادرست کند، بدون این‌که هیچ داده‌ای واقعاً حذف یا تغییر کرده باشد. مشابه آن، تابع‌های تجمیعی (مثل SUM یا COUNT) وقتی روی دادهٔ تکراری اعمال شوند، می‌توانند نتیجه‌ای بدهند که به‌ظاهر معتبر اما در واقع دو یا چند برابر مقدار واقعی است. این دسته از خطاها خطرناک‌ترند چون هیچ هشداری تولید نمی‌کنند — کوئری بدون خطا اجرا می‌شود و عددی برمی‌گرداند که فقط با مقایسه با یک منبع مستقل (مثلاً یک گزارش قبلی) قابل کشف است.

وقتی کوئری روی سیستم تولید اجرا می‌شود

حتی کوئری‌های فقط-خواندنی (SELECT) می‌توانند مشکل‌ساز باشند اگر روی جدول‌های بزرگ بدون ایندکس مناسب اجرا شوند و بار سنگینی به دیتابیس تولید تحمیل کنند. عادت خوب این است که برای کوئری‌های اکتشافی یا گزارش‌گیری سنگین، از یک replica فقط-خواندنی جدا از دیتابیس اصلی استفاده شود تا کندی یا قفل‌شدن جدول، روی کاربران واقعی سیستم اثر نگذارد.

جمع‌بندی

• هیچ‌وقت کوئری تولیدشده توسط AI را بدون خواندن کامل آن اجرا نکنید؛ ظاهر معتبر بودن به‌معنای درست بودن نیست.
• یک UPDATE یا DELETE بدون WHERE می‌تواند کل جدول را تحت تأثیر قرار دهد یا پاک کند — این اولین چیزی است که باید چک کنید.
• پیش از هر عملیات نوشتن، همان شرط را با SELECT COUNT(*) تست کنید و تعداد ردیف‌ها را با انتظار خود مقایسه کنید.
• روی staging یا در یک تراکنش قابل ROLLBACK اجرا کنید، و پیش از تغییرات بزرگ backup بگیرید.
• دسترسی دیتابیسی ابزار AI را به کمترین حد لازم (ترجیحاً فقط خواندن) محدود کنید.