پروژه‌های SQL توهمات هوش مصنوعی را به خطاهای ساختاری تبدیل می‌کنند

تصور کنید یک برنامه‌نویس هستید که از هوش مصنوعی برای نوشتن کوئری‌های پیچیده SQL استفاده می‌کند؛ کد در ظاهر بی‌نقص است، اما در لحظه اجرا با خطای «ستون ناموجود» متوقف می‌شود یا از تابعی استفاده می‌کند که در نسخه سرور شما پشتیبانی نمی‌شود. این شکست‌های خاموش، بزرگ‌ترین نقطه ضعف توسعه دیتابیس با ابزارهای هوش مصنوعی هستند. این چالش‌ها یادآور خطاهای بحرانی در سایر بخش‌های توسعه است، جایی که یک اشتباه کوچک در کدهای تولید شده توسط AI توانست کل سیستم احراز هویت یک پروژه را متوقف کند.

به گزارش یک راهنمای فنی در dev.to در ۲۴ سپتامبر ۲۰۲۶، تغییر رویکرد به «پروژه‌های پایگاه‌داده SQL» (SQL Database Projects) این شکست‌های پنهان را به خطاهای ساختاری (Build Errors) تبدیل می‌کند که به‌راحتی قابل شناسایی و اصلاح هستند. این موضوع به‌ویژه از آن جهت حیاتی است که در دنیای دیتابیس، برخلاف زبان‌هایی مثل C#، معمولاً کامپایلری وجود ندارد که پیش از اجرای اسکریپت روی محیط عملیاتی، اشتباهات را فریاد بزند؛ بنابراین در بسیاری از موارد، تنها برنامه‌نویس و یک اسکریپت هستند که منتظرند دیتابیس در لحظه اجرا بفهمد کد اشتباه است.

بیشتر توسعه‌دهندگان دیتابیس به یک گردش‌کار امری (Imperative) عادت کرده‌اند. آن‌ها مجموعه‌ای از اسکریپت‌های مهاجرت (Migration) را می‌نویسند؛ مثلاً ابتدا یک جدول را می‌سازند و ماه‌ها بعد ستونی به آن اضافه می‌کنند. این روند منجر به ایجاد زنجیره‌ای شکننده از فایل‌ها می‌شود که باید با ترتیبی دقیق و بدون خطا اجرا شوند. پس از یک سال، ممکن است توسعه‌دهنده‌ای پوشه‌ای با ۸۰ اسکریپت داشته باشد که همگی باید به‌طور کامل و درست اجرا شوند. این روش برای عامل‌های هوش مصنوعی (AI Agents) یک کابوس است، زیرا آن‌ها اغلب دسترسی به زمینه (Context) کامل وضعیت فعلی دیتابیس ندارند و در نوشتن مسیرهای مهاجرتی بی‌نقص که با تاریخچه دیتابیس سازگار باشد، شکست می‌خورند.

پروژه‌های SQL این مدل را با یک رویکرد توصیفی (Declarative) جایگزین می‌کنند. در این حالت، به‌جای اینکه به دیتابیس بگویید «چگونه» تغییر کند، توصیف می‌کنید که وضعیت نهایی «چه» باشد. جداول، ویوها (Views) و رویه‌های ذخیره شده (Stored Procedures) شما به‌عنوان فایل‌های .sql در مخزن گیت ذخیره می‌شوند و مانند یک نقشه جامع (Blueprint) برای کل طرحواره عمل می‌کنند. برای توسعه‌دهندگان .NET، این دقیقاً مشابه فایل .csproj است، اما برای دیتابیس. شما فایل‌ها را می‌نویسید، پروژه را Build می‌کنید و خروجی‌ای می‌گیرید که قابل استقرار است.

درک رویکرد توصیفی

در یک سیستم توصیفی، هر شیء تنها یک‌بار در یک فایل تعریف می‌شود. برای مثال، یک جدول به این صورت تعریف می‌شود:

CREATE TABLE [dbo].[Customers] ( [Id] INT NOT NULL PRIMARY KEY, [Name] NVARCHAR(100) NOT NULL, [Email] NVARCHAR(256) NOT NULL );

اگر نیاز داشته باشید یک ستون شماره تلفن اضافه کنید، به‌جای نوشتن یک اسکریپت ALTER TABLE، صرفاً فایل موجود را ویرایش کرده و عبارت [PhoneNumber] NVARCHAR(20) NULL را به آن اضافه می‌کنید. این کار شبیه این است که به‌جای دادن لیستی از دستورات تخریب دیوارها به یک بنا، نقشه نهایی خانه را به او بدهید. بنای ساختمان خودش محاسبه می‌کند که چه تغییراتی لازم است تا خانه با نقشه مطابقت داشته باشد.

سازوکار «کامپایلر دیتابیس»

وقتی دستور dotnet build را روی یک پروژه SQL اجرا می‌کنید، سیستم دو مرحله اعتبارسنجی حیاتی را انجام می‌دهد که به‌عنوان حقیقت‌سنج برای کدهای تولیدشده توسط هوش مصنوعی زاینده (Generative AI) عمل می‌کند:

• اعتبارسنجی ارجاعات (Reference Validation): سیستم تضمین می‌کند که هر شیء مورد ارجاع واقعاً وجود داشته باشد. اگر هوش مصنوعی ویویی بسازد که به ستونی به نام Phone ارجاع دهد، در حالی که نام واقعی ستون در جدول PhoneNumber است، عملیات Build خطای ارجاع حل‌نشده (SQL71501) را صادر می‌کند. این یک حلقه بازخورد (Feedback Loop) ایجاد می‌کند که در آن عامل هوش مصنوعی می‌تواند تغییر را اعمال کند، پروژه را Build کند، خطا را بخواند و به‌طور خودکار آن را اصلاح کند.
• هدف‌گذاری پلتفرم (Platform Targeting): ساختار کد با یک پلتفرم هدف خاص سنجیده می‌شود. اگر پروژه برای SQL Server 2017 هدف‌گذاری شده باشد، عملیات Build توابع JSON را که تنها در SQL Server 2022 معرفی شده‌اند، رد می‌کند.

پس از اعتبارسنجی، پروژه یک فایل .dacpac تولید می‌کند. این مصنوع ساخت (Build Artifact) در واقع بسته‌ای است که شامل کل طرحواره است. این فایل توسط ابزار SqlPackage مستقر می‌شود؛ ابزاری که نقشه (Blueprint) را با دیتابیس زنده مقایسه کرده و به‌طور خودکار تغییرات لازم برای رسیدن به آن وضعیت را تولید می‌کند.

جزئیات استقرار

ابزار SqlPackage کارهای دشوار و پیچیده فرآیند استقرار را بر عهده می‌گیرد:

• ترتیب اجرا (Ordering): تضمین می‌کند اشیاء با ترتیب درست ساخته شوند؛ مثلاً ابتدا جدول ساخته شود و سپس کلید خارجی (Foreign Key) که به آن اشاره می‌کند.
• تغییرات تدریجی (Incremental Changes): اگر ستون‌هایی کم باشند، دستور ALTER TABLE تولید می‌کند و اگر یک رویه ذخیره شده تغییر کرده باشد، دستور ALTER PROCEDURE را می‌سازد.
• مقایسه (Comparison): فایل .dacpac را با دیتابیس موجود مقایسه کرده و تنها تغییرات خاصی که برای رسیدن به وضعیت مطلوب لازم است را تولید می‌کند.

یکپارچه‌سازی با هوش مصنوعی و ابزارها

عامل‌های هوش مصنوعی برای عملکرد درست به زمینه (Context) نیاز دارند و پروژه‌های SQL کل طرحواره را به‌صورت متن ساده در اختیار آن‌ها قرار می‌دهند. این یعنی دیگر نیازی نیست رشته اتصال (Connection String) خطرناک دیتابیس عملیاتی را به هوش مصنوعی بدهید؛ عامل صرفاً فایل‌های .sql را در مخزن می‌خواند تا انواع داده‌ها و کلیدهای خارجی را درک کند. همچنین وجود هر شیء در یک فایل مجزا، جستجو و خواندن طرحواره را برای هوش مصنوعی آسان می‌کند.

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

sqlpackage /Action:Extract /SourceConnectionString:"<your connection string>" /TargetFile:MyDatabase /p:ExtractTarget=SchemaObjectType

این استخراج فارغ از نحوه ساخت دیتابیس (حتی دیتابیس‌هایی که توسط ORMهایی مثل EF Core مدیریت شده‌اند) کار می‌کند. این قابلیت به تیم‌ها اجازه می‌دهد بدون تغییر در گردش‌کار فعلی، تصویری خوانا از طرحواره خود را در اختیار ابزارهای هوش مصنوعی قرار دهند.

ابزارها و فرمت‌ها

ابزارهای مدرن اکنون از فرمت SDK-style (با استفاده از Microsoft.Build.Sql) پشتیبانی می‌کنند. این فرمت جدید برای توسعه‌های جدید توصیه می‌شود و در آینده فرمت اصلی مورد پشتیبانی خواهد بود. این مدل Cross-platform است، روی نسخه‌های مدرن .NET اجرا می‌شود و از ارجاعات NuGet برای دیتابیس‌ها پشتیبانی می‌کند. همچنین تمام فایل‌های .sql موجود در پوشه پروژه را به‌طور خودکار شامل می‌شود.

پشتیبانی در محیط‌های مختلف (IDE) متفاوت است:

• VS Code: پروژه‌های SDK-style به‌طور کلی از طریق افزونه SQL Database Projects در دسترس هستند.
• JetBrains Rider: نسخه 2025.2 به بعد شامل پلاگین‌های داخلی برای قالب‌های پروژه، وارد کردن از دیتابیس‌های موجود، مقایسه طرحواره (Schema Compare) و انتشار (Publishing) است.
• Visual Studio 2022: این قابلیت‌ها به‌عنوان یک جزء پیش‌نمایش (Preview Component) موجود هستند.
• Visual Studio 2026: در حال حاضر تنها از فرمت قدیمی مبتنی بر .NET Framework پشتیبانی می‌کند که عمدتاً به ویندوز وابسته بود.

برای شروع با فرمت SDK، سه دستور ساده کافی است:

1. dotnet new install Microsoft.Build.Sql.Templates
2. dotnet new sqlproj -n MyDatabase
3. dotnet build

ایجاد حفاظ‌های ایمنی برای هوش مصنوعی

برای عملیاتی کردن این گردش‌کار، توسعه‌دهندگان می‌توانند یک فایل دستورالعمل (Instructions file) خاص در مخزن قرار دهند. این فایل باید موارد زیر را الزامی کند:

• طرحواره دیتابیس در مسیر /database به‌عنوان یک پروژه SQL قرار دارد.
• هر شیء باید تنها یک‌بار در فایل مخصوص به خود تعریف شود.
• هوش مصنوعی هرگز نباید دستورات ALTER یا اسکریپت‌های مهاجرت بنویسد.
• هوش مصنوعی باید دستور dotnet build database/MyDatabase.sqlproj را اجرا کرده و تمام خطاها را پیش از ادامه کار اصلاح کند.
• پلتفرم هدف (مثلاً SQL Server 2022) باید به‌طور سخت‌گیرانه رعایت شود تا از استفاده از ویژگی‌های نسخه‌های جدیدتر جلوگیری شود.

لایه‌های امنیتی تکمیلی

علاوه بر مرحله Build، توسعه‌دهندگان می‌توانند حفاظ‌های بیشتری را پیاده‌سازی کنند:

• تحلیل کد (Code Analysis): فعال کردن <RunSqlCodeAnalysis>True</RunSqlCodeAnalysis> در فایل پروژه، عادت‌های بد هوش مصنوعی، مانند استفاده مکرر از SELECT * در ویوها و رویه‌های ذخیره شده را شناسایی می‌کند. این قوانین را می‌توان سفارشی کرد یا با قوانین جدید گسترش داد.
• گزارش‌های استقرار (Deployment Reports): استفاده از /Action:Script به انسان‌ها اجازه می‌دهد اسکریپتی را که قرار است اجرا شود تولید کرده و آن را بررسی کنند، به‌جای اینکه بلافاصله اجرا شود. همچنین /Action:DeployReport یک نمای کلی از تغییرات ارائه می‌دهد.
• نقاط بازبینی (Review Moments): این سیستم دو نقطه بازبینی مجزا ایجاد می‌کند: تفاوت‌های گیت (Git diff) در فایل‌های .sql و اسکریپت نهایی استقرار. هیچ تغییری بدون اینکه چشم انسان آن را ببیند به دیتابیس واقعی نمی‌رسد.

محدودیت‌های حیاتی

با وجود تمام مزایا، این سیستم جایگزین کامل نظارت انسانی نیست. تغییر نام یک ستون (Renaming) عملیاتی پرخطر است؛ هوش مصنوعی که یک فایل متنی را ویرایش می‌کند، ممکن است باعث تحریک عملیات «حذف و ساخت مجدد» (drop and create) شود که منجر به از دست رفتن داده‌ها می‌گردد. اگرچه SqlPackage به‌طور پیش‌فرض استقرارهای منجر به حذف داده را مسدود می‌کند، اما توسعه‌دهندگان باید «لاگ بازسازی» (Refactor Log) را برای تغییر نام‌ها به‌صورت دستی مدیریت کنند، زیرا عامل‌های هوش مصنوعی هنگام ویرایش فایل‌های متنی، این لاگ‌ها را به‌طور خودکار ایجاد نمی‌کنند.

علاوه بر این، پروژه‌های SQL طرحواره (Schema) را مدیریت می‌کنند، نه داده‌ها را. هرگونه تبدیل یا جابه‌جایی پیچیده داده‌ها همچنان به اسکریپت‌های دستی پس از استقرار (Post-deployment scripts) نیاز دارد. یک Build سبز تایید می‌کند که طرحواره معتبر است و سینتکس برای پلتفرم هدف درست است، اما تضمین نمی‌کند که طراحی معماری صحیح باشد. بازبینی منطق کد همچنان بر عهده انسان است.

این تغییر رویکرد در واقع یک کامپایلر به دیتابیس می‌دهد. با تفکیک کار — سپردن توصیف مقصد (وضعیت توصیفی) به هوش مصنوعی و سپردن مسیر مهاجرت به ابزاری قطعی مثل SqlPackage — توسعه‌دهندگان می‌توانند تغییرات دیتابیس را با همان سخت‌گیری کدهای C# بررسی کنند. این سیستم یک شبکه ایمنی برای توسعه‌دهندگان جونیور و یک حلقه اتوماسیون قدرمند برای مهندسان با تجربه فراهم می‌کند که اکنون می‌توانند از Build برای بررسی صحت کار هوش مصنوعی استفاده کنند.

گام بعدی شما

• اگر از EF Core استفاده می‌کنید، سعی کنید طرحواره خود را با sqlpackage استخراج کرده و در یک پروژه SQL قرار دهید تا از قابلیت اعتبارسنجی بهره ببرید.
• یک فایل .cursorrules یا دستورالعمل سیستمی برای عامل هوش مصنوعی خود بنویسید و او را مجبور کنید پیش از ارائه کد، دستور dotnet build را اجرا کند.
• برای تغییر نام ستون‌ها، به‌جای تکیه بر هوش مصنوعی، از Refactor Logهای رسمی مایکروسافت استفاده کنید تا از حذف داده‌ها جلوگیری شود.

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