Microsoft SQL منتصف 2026: التحول الهادئ من محرك قاعدة بيانات إلى منصة بيانات AI

Emiliano Montesdeoca — Sun, 19 Jul 2026 00:00:00 +0000

النصف الأول من 2026 لـ Microsoft SQL ليس مجرد قائمة إصدارات طويلة. إنه إشارة اتجاهية. SQL Server و Azure SQL و SQL database in Fabric تتقارب نحو وضعية منصة حيث البيانات والحوكمة وسير عمل AI مصممة للتعايش بدلاً من أن تُربط معًا.

المصدر الأصلي: https://devblogs.microsoft.com/azure-sql/whats-new-across-microsoft-sql-in-2026-so-far-sql-server-azure-sql-and-sql-database-in-fabric/

على طبقة المحرك، ميزات GA مثل AI_GENERATE_EMBEDDINGS وكائنات النموذج الخارجي وضوابط هوية مستوى الخادم Entra تظهر أن “AI في سير عمل قاعدة البيانات” أصبح الآن سائدًا، وليس مجرد معاينة جديدة. على الطبقة التشغيلية، تحسينات Hyperscale و Managed Instance وخيارات تشفير أقوى وتحديثات CU منتظمة تشير إلى أن انضباط الموثوقية والأمان الكلاسيكي لا يزال سليمًا.

قصة الأدوات مهمة بنفس القدر. SSMS يحصل على وضع وكيل Copilot ومقارنة المخطط وتحسينات منسق SQL وسياق تنفيذ أغنى. إضافة MSSQL في VS Code تواصل دفع دفاتر الملاحظات وتصميم المخطط بمساعدة AI وتكامل DAB وسير عمل توفير Azure. هذا الاستثمار ثنائي المسار يقول إن Microsoft تتوقع من المطورين البقاء متعددي اللغات في اختيار IDE مع التوحيد على قدرات مستوى البيانات المشتركة.

أقوى رأيي: SQL MCP Server هو الاتجاه المركزي. بمجرد أن يتم كشف كيانات SQL بشكل آمن كواجهات قابلة للأدوات للوكلاء، تتوقف قاعدة البيانات عن كونها تخزينًا سلبيًا وتصبح مشاركًا نشطًا في التنسيق. هذا يخلق رافعة جديدة، لكنه يرفع أيضًا معيار الهندسة الأمنية ونشر الهوية وقابلية التدقيق.

ما الذي يجب أن تفعله الفرق الآن؟

اختر مسار ترحيل واحد ونفذه بقوة. إما حدث مسار المخطط/التطوير الخاص بك حول SQL Projects بالإضافة إلى CI/CD، أو ركز على حوكمة جاهزة لـ MCP وضوابط الوصول إلى البيانات. محاولة استيعاب كل إعلان ميزة بالتوازي ستعطل التوصيل. أيضًا، أنشئ خط أساس هوية واحد مع مصادقة Entra حيثما أمكن. أنماط المصادقة المختلطة هي أسرع طريق لتنفيذ سياسات غير متناسق.

أخيرًا، تعامل مع تحديثات النظام البيئي للمشغلات كعمل حاسم للإنتاج، وليس ضجيج صيانة. SqlClient و ODBC و OLE DB وموصلات Python ومحولات Django — جميعها شحنت تغييرات موثوقية وتوافق هادفة. إذا كانت مكدس تطبيقك يمتد عبر اللغات، فإن موثوقية بياناتك قوية فقط بقدر أقل مشغل مُحدّث في الإنتاج.

هذه هي الرسالة الحقيقية لعام 2026 حتى الآن: Microsoft SQL يصبح النواة التشغيلية للأنظمة الوكيلية. الفرق التي تحدث مع وضع الحوكمة في الاعتبار ستتحرك أسرع. الفرق التي تطارد الميزات دون انضباط منصاتي ستراكم تعقيدًا مكلفًا.

SQL Server 2025 كقاعدة بيانات جاهزة للوكلاء: الأمان والنسخ الاحتياطي وMCP في محرك واحد

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

تمت ترجمة هذه المقالة تلقائيًا. للنسخة الأصلية، انقر هنا.

لقد تابعت سلسلة Polyglot Tax من Aditya Badramraju باهتمام كبير. الأجزاء 1-3 قدّمت حجة مقنعة لصالح SQL Server 2025 كقاعدة بيانات متعددة النماذج بحق — JSON والرسوم البيانية والمتجهات والبيانات العلائقية كلها في محرك واحد مع مخطط استعلام موحّد. الجزء الرابع يختم السلسلة بالجزء الذي يحدد فعلاً ما إذا كنت ستثق بهذه البنية في الإنتاج.

الخلاصة: قصة الإنتاج قوية.

نموذج أمان واحد لكل نماذج البيانات

هذه هي المشكلة مع البنى متعددة اللغات: عندما يسألك المدقق “أثبت أن Tenant A لا يستطيع رؤية بيانات Tenant B”، عليك الإجابة عن هذا السؤال لكل قاعدة بيانات على حدة. خمس قواعد بيانات، خمس نماذج أمان، خمس براهين.

مع SQL Server 2025، يمكنك تعريف سياسة Row-Level Security واحدة تغطي كل نماذج البيانات:

CREATE FUNCTION dbo.fn_TenantFilter(@TenantID INT)
RETURNS TABLE WITH SCHEMABINDING
AS RETURN SELECT 1 AS fn_result
WHERE @TenantID = CAST(SESSION_CONTEXT(N'TenantID') AS INT);

CREATE SECURITY POLICY TenantIsolation
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Customers, -- Relational
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Events, -- JSON data
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Relationships, -- Graph edges
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Embeddings -- Vector data
WITH (STATE = ON);

من تلك اللحظة، أي استعلام — joins علائقية، استعلامات مسارات JSON، اجتيازات الرسوم البيانية، بحث تشابه المتجهات — يُفلتر تلقائيًا حسب tenant. المحرك يحقن الشرط في خطة التنفيذ قبل أن تغادر أي بيانات التخزين. الشيفرة التي تستدعيه لا تحتاج إلى WHERE TenantID = @id في كل مكان. تختبر السياسة مرة واحدة.

تتراصف الطبقات كذلك: Dynamic Data Masking للأعمدة التي لا ينبغي أن ترى قيمها الكاملة بعض الأدوار، وAlways Encrypted للتشفير من طرف إلى طرف (حتى مسؤولو قواعد البيانات لا يستطيعون قراءتها)، والإجراءات المخزنة كحدّ للامتيازات بحيث لا تستدعي الوكلاء إلا ما كشفته لهم صراحة.

هذا هو الجزء من البنية الذي يهم أكثر في SaaS الخاضع للامتثال. سياسة واحدة، وبُرهان واحد.

نسخ احتياطي موحّد = استعادة ذرّية

أمر واحد، كل نماذج البيانات، ونقطة زمنية متسقة:

BACKUP DATABASE MultiModelApp
TO URL = 'https://storage.blob.core.windows.net/backups/MultiModelApp.bak'
WITH COMPRESSION, ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupCert);

RESTORE DATABASE MultiModelApp
FROM URL = 'https://storage.blob.core.windows.net/backups/MultiModelApp.bak'
WITH STOPAT = '2026-02-01 10:30:00';

في stack متعدد اللغات، تعني استعادة نقطة زمنية عبر خمس قواعد بيانات تنسيق خمس عمليات استعادة والأمل في أن تتطابق الطوابع الزمنية في حدود ثانية أو ثانيتين. بالنسبة للبيانات المالية، هذا التفاوت غير مقبول. مع قاعدة بيانات واحدة، وسجل معاملات واحد، واستعادة واحدة — الاسترداد ذرّي بحكم التعريف.

جداول Ledger لمسارات تدقيق لا يمكن العبث بها

في القطاعات المنظمة، أنت تحتاج إلى أكثر من “لدينا سجلات”. أنت تحتاج إلى دليل مشفّر على أن تلك السجلات لم تُعدّل:

CREATE TABLE FinancialTransactions (
 TransactionID INT PRIMARY KEY,
 AccountID INT NOT NULL,
 Amount MONEY NOT NULL,
 TransactionType NVARCHAR(20),
 TransactionDate DATETIME2 DEFAULT SYSUTCDATETIME()
)
WITH (SYSTEM_VERSIONING = ON, LEDGER = ON);

كل عملية insert وupdate وdelete تُhashed تشفيريًا داخل بنية شبيهة بالبلوكشين. يمكنك أن تثبت للمدقق — رياضيًا — أن صفًا لم يتم العبث به منذ كتابته. في stack متعدد اللغات، هذه القدرة لا تتوفر بشكل موحّد عبر قواعد البيانات كلها.

تكامل MCP: وكلاء بلا middleware مكتوب يدويًا

السلسلة كانت تتجه إلى هذا: SQL Server 2025 يدعم SQL MCP Server مباشرة، وهذا يعني أن وكلاءك يمكنهم استدعاء قاعدة البيانات عبر نداءات أدوات طبيعية دون أن تكتب middleware لكل عملية.

ادمج ذلك مع الإجراءات المخزنة كحد للامتيازات وRow-Level Security المطبقة على مستوى المحرك، وستحصل على نموذج حيث:

يستدعي الوكيل أداة، مثل “احصل على سياق العميل للحساب 12345”
يترجم MCP ذلك إلى الإجراء المخزن الذي حددته
يفرض محرك SQL عزل tenant وإخفاء الأعمدة تلقائيًا
يحصل الوكيل على البيانات المسموح له برؤيتها فقط

لا توجد طبقة middleware. لا يوجد خطر حقن استعلامات عشوائية. المحرك هو من يتولى التفويض، وليس الوكيل.

لماذا يهم هذا لمطوري .NET

إذا كنت تبني خدمات .NET وSQL Server هو مخزن البيانات الأساسي لديك، فهذه الرسالة من السلسلة هي: لست بحاجة إلى إضافة Redis للتخزين المؤقت، أو قاعدة بيانات رسومية للعلاقات، أو مخزن متجهات للتمثيلات — SQL Server 2025 يتولى كل ذلك، مع اتساق تشغيلي أفضل من stack متعدد اللغات وأمان موحّد يمكن تدقيقه فعلاً.

تكامل MCP يعني أن وكلاء Semantic Kernel أو سير عمل Microsoft Agent Framework يمكنهم التفاعل مع طبقة البيانات لديك عبر SQL MCP Server نفسه، وبنفس ضمانات الأمان التي ستفرضها على الاستعلامات البشرية.

الختام

سلسلة Polyglot Tax تستحق القراءة من البداية إلى النهاية. الأجزاء 1-3 تثبت قصة مخطط الاستعلام. الجزء 4 يثبت قصة الإنتاج. بالنسبة لمطوري .NET الذين يبنون تطبيقات agent-first أو AI-augmented على Azure SQL، تستحق هذه البنية اعتبارًا جديًا.

المقال الأصلي بقلم Aditya Badramraju: The Polyglot Tax – Part 4.

SQL Server | The .NET Blog