إدارة أعمدة وفهارس JSON
تعمل قواعد البيانات العلائقية بشكل أفضل عندما يكون كل صف في الجدول يحتوي على نفس الأعمدة. تحدد الهيكل مرة واحدة، وكل سجل يتبعه. يعمل هذا التصميم بشكل جيد مع بيانات مثل العملاء أو الطلبات أو الفواتير حيث تكون الحقول متوقعة. لكن بعض البيانات تختلف من سجل لآخر. السمات التي تحتاج إلى تخزينها تعتمد على نوع العنصر، أو مصدر البيانات، أو الخيارات التي يتخذها المستخدمون. تصميم الجداول التقليدي يجبرك إما على إنشاء العديد من الأعمدة الفارغة لمعظم الصفوف، أو تقسيم البيانات عبر جداول متعددة. تقدم أعمدة JSON خيارا آخر: تخزين الأجزاء المتغيرة ك JSON مع الاحتفاظ بالأجزاء المتوقعة في الأعمدة العادية.
على سبيل المثال، يحتوي كتالوج منتجات التجارة الإلكترونية على حقول مشتركة مثل اسم المنتج، السعر، والفئة التي تنطبق على كل منتج. لكن القميص يحتاج إلى الحجم واللون، واللابتوب يحتاج إلى سرعة المعالج وحجم الشاشة، والكتاب يحتاج إلى مؤلف وصفات أخرى. مع JSON، تخزن الحقول المشتركة كأعمدة وتضع السمات الخاصة بالفئة في عمود JSON. يمكنك إضافة أنواع منتجات جديدة دون تغيير هيكل الجدول.
فهم متى تستخدم أعمدة JSON
أعمدة JSON تتيح لك الاستعلام وفهرسة البيانات شبه المنظمة باستخدام صياغة SQL المألوفة. لا تحتاج إلى قاعدة بيانات NoSQL منفصلة للتعامل مع البيانات المرنة. فكر في JSON لهذه السيناريوهات:
- تفضيلات المستخدم - الإعدادات مثل القالب واللغة وخيارات الإشعارات تختلف من مستخدم لآخر وتتغير مع إضافة الميزات.
- استجابات واجهات برمجة التطبيقات - البيانات من الخدمات الخارجية لها هياكل متداخلة قد تتغير عند تحديث المزود لواجهة برمجة التطبيقات الخاصة به.
- سجلات التدقيق - السجلات التي تلتقط الحالات قبل وبعد تحتاج إلى التكيف مع تطور مخططات الجداول.
- تطبيقات متعددة المستأجرين - يحتاج العملاء المختلفون إلى حقول مخصصة مختلفة.
- بيانات وصفية مرنة - الوسوم، التسميات، والخصائص تختلف حسب السجل ولا تناسب مخططا ثابتا.
إنشاء واستعلام أعمدة JSON
يقدم SQL Server 2025 نوع بيانات json أصلي يخزن مستندات JSON بصيغة ثنائية محسنة للاستعلام والمعالجة. يوفر النوع الأصلي قراءات أكثر كفاءة (المستند محلل بالفعل)، وكتابة أكثر كفاءة (يمكن للتحديثات تعديل القيم الفردية دون إعادة كتابة المستند بالكامل)، وضغط تخزين أفضل مقارنة بتخزين JSON ك.NVARCHAR(MAX)
في الإصدارات السابقة من SQL Server، تقوم بتخزين JSON في NVARCHAR(MAX) عمود.
لقراءة القيم من JSON، تستخدم دوال JSON مثل JSON_VALUE استخراج قيمة واحدة أو JSON_QUERY لإرجاع كائن أو مصفوفة. إذا كنت تستعل خاصية JSON بشكل متكرر، يمكنك إنشاء فهرس على عمود محسوب يستخرج تلك الخاصية.
المثال التالي ينشئ جدولا بعمود JSON، ويدرج مستندات، ويستعل خصائص محددة، ويحدث القيم، وينشئ فهرسا على حقل يتم الوصول إليه كثيرا:
-- Create table with native JSON type (SQL Server 2025+)
CREATE TABLE ConfigurationData (
ConfigID INT PRIMARY KEY,
ConfigSettings JSON NOT NULL
);
-- Insert JSON documents
INSERT INTO ConfigurationData (ConfigID, ConfigSettings)
VALUES (1, '{"theme":"dark","language":"en","notifications":true}');
INSERT INTO ConfigurationData (ConfigID, ConfigSettings)
VALUES (2, '{"theme":"light","language":"fr","notifications":false}');
-- Query JSON properties
SELECT ConfigID,
JSON_VALUE(ConfigSettings, '$.theme') AS Theme,
JSON_VALUE(ConfigSettings, '$.language') AS Language,
JSON_QUERY(ConfigSettings, '$') AS FullConfig
FROM ConfigurationData;
-- Update a single property using the modify method (SQL Server 2025+ preview)
UPDATE ConfigurationData
SET ConfigSettings.modify('$.theme', 'light')
WHERE ConfigID = 1;
-- Alternative: JSON_MODIFY works with both JSON and NVARCHAR(MAX) columns
UPDATE ConfigurationData
SET ConfigSettings = JSON_MODIFY(CAST(ConfigSettings AS NVARCHAR(MAX)), '$.notifications', CAST(0 AS BIT))
WHERE ConfigID = 1;
-- Create index on frequently queried JSON property
ALTER TABLE ConfigurationData
ADD ThemeValue AS JSON_VALUE(ConfigSettings, '$.theme');
CREATE INDEX IX_Theme ON ConfigurationData(ThemeValue);
هذا المثال ينشئ جدولا يحتوي على JSON عمود يخزن إعدادات إعدادات المستخدم. تضيف العبارات INSERT مستندات JSON كرموز نصية. لقراءة قيم محددة، JSON_VALUE يستخرج القيم القياسية مثل القالب واللغة، بينما JSON_QUERY يعيد كائن JSON بالكامل.
.modify() الطريقة (حاليا في المعاينة) تحدث خاصية واحدة دون إعادة كتابة المستند بالكامل. نظرا لأن النوع json لا يمكن استخدامه كعمود مفتاح فهرس، فإن المثال ينشئ عمودا محسوبا يستخرج قيمة السمة، ثم يفهرس ذلك العمود المحسوب.
اجمع بين البنية العلائقية والبنية JSON
أعمدة JSON تعمل بشكل أفضل للبيانات التي تختلف حسب السجل. إذا كان لكل صف نفس الحقول مع أنواع بيانات متسقة، فإن الأعمدة العادية تكون أكثر توافقا. تحصل على التحقق الأصلي من نوع البيانات، واستعلامات أبسط بدون بناء مسار JSON، وفهرسة مباشرة على الأعمدة. استخدم JSON للأجزاء من بياناتك التي تحتاج إلى مرونة، واحتفظ بالأجزاء المتوقعة في أعمدة مكتوبة.
يمكنك دمج البنية العلائقية مع مرونة JSON للمنتجات التي تتطلب بيانات وصفية متغيرة. إليك مثال:
-- Product with flexible metadata (SQL Server 2025+)
CREATE TABLE ProductMetadata (
ProductID INT PRIMARY KEY,
AdditionalAttributes JSON NOT NULL
CHECK (JSON_PATH_EXISTS(AdditionalAttributes, '$.weight') = 1),
FOREIGN KEY (ProductID) REFERENCES Product(ProductID)
);
-- Store flexible product attributes
INSERT INTO ProductMetadata (ProductID, AdditionalAttributes)
VALUES (1, '{"dimensions":{"length":10,"width":5,"height":8},"weight":2.5,"color":"blue"}');
-- Query nested JSON properties
SELECT ProductID,
JSON_VALUE(AdditionalAttributes, '$.weight') AS Weight,
JSON_VALUE(AdditionalAttributes, '$.dimensions.length') AS Length
FROM ProductMetadata;
ضع في اعتبارك مبادئ تصميم JSON
طبق هذه المبادئ عند تنفيذ أعمدة JSON:
- استخدم JSON للبيانات شبه المنظمة - قم بتخزين هياكل بيانات مرنة تختلف حسب السجل، وليس البيانات ذات المخططات المتسقة.
- المسارات التي يتم الاستعلام عنها كثيرا - أنشئ أعمدة محسوبة تحتوي على فهارس على خصائص JSON التي تستسلم إليها كثيرا.
-
التحقق من الخصائص المطلوبة - استخدم
CHECKالقيود معJSON_PATH_EXISTSلضمان وجود الحقول المطلوبة. - وازن المرونة مع البنية - احتفظ بالبيانات المتوقعة في الأعمدة العادية واستخدم JSON فقط للأجزاء المتغيرة.
توفر أعمدة JSON مرونة في المخطط لبيانات المتغيرات مع الحفاظ على قدرات استعلام SQL، لكنها يجب أن تكمل التصميم العلائقي للبيانات المنظمة بدلا من أن تحل محلها.