مقدمه و نقشه راه

نوع داده xml در SQL Server فقط محلی برای ذخیره یک رشته دارای علامت‌های زاویه‌دار نیست؛ موتور پایگاه داده آن را به‌عنوان ساختاری سلسله‌مراتبی می‌شناسد و مجموعه‌ای از متدهای اختصاصی برای خواندن، آزمودن، خردکردن و تغییر آن ارائه می‌کند. پنج متد value()، query()، exist()، nodes() و modify() هسته این ابزارها هستند. انتخاب درست میان آن‌ها بر صحت نوع خروجی، خوانایی Query، امکان بهینه‌سازی و حتی مقدار لاگ تولیدشده هنگام Update اثر مستقیم دارد.

این راهنما ابتدا مدل ذهنی لازم برای کار با XML، XQuery، Context Item، Namespace و تایپ ایستا را می‌سازد؛ سپس کاربرد هر متد را با لینک مقاله مستقل و مثال اجرایی نشان می‌دهد. هدف این است که توسعه‌دهنده بتواند از یک نمونه کوچک عبور کند و همان الگو را با کنترل خطا، امنیت، کارایی و قابلیت نگهداری در سامانه سازمانی به کار ببرد.

قاعده انتخاب سریع: اسکالر را با value()، قطعه XML را با query()، آزمون وجود را با exist()، مجموعه گره‌ها را با nodes() و تغییر سند را با modify() انجام دهید.

دسترسی سریع به مقاله‌های تخصصی

• آموزش کامل متد value()
• آموزش کامل متد query()
• آموزش کامل متد exist()
• آموزش کامل متد nodes()
• آموزش کامل متد modify()

نوع داده XML و تفاوت آن با متن

وقتی مقدار در ستونی از نوع xml ذخیره می‌شود، SQL Server صحت شکلی سند یا Fragment را بررسی می‌کند، کاراکترها را به نمایش داخلی مناسب می‌برد و اجرای XQuery را ممکن می‌سازد. در مقابل، nvarchar فقط رشته است و موتور درباره عنصر، Attribute، ترتیب والد و فرزند یا Namespace آگاهی ساختاری ندارد. تبدیل مکرر متن به xml هم هزینه CPU دارد و هم خطا را از زمان ورود داده به زمان اجرای گزارش منتقل می‌کند.

XML می‌تواند untyped یا typed باشد. در XML بدون نوع، ساختار به XML Schema Collection متصل نیست و انعطاف بیشتری دارد. در XML نوع‌دار، Schema دامنه مقادیر و ساختار را محدود می‌کند، تایپ ایستا اطلاعات بیشتری دارد و بعضی خطاها زودتر آشکار می‌شوند. در عوض، تغییر Schema و مهاجرت داده نیازمند برنامه دقیق‌تری است. انتخاب میان این دو باید از قرارداد داده، عمر پیام و الزامات اعتبارسنجی شروع شود.

هر سند XML ممکن است Namespace پیش‌فرض یا پیشونددار داشته باشد. Namespace بخشی از هویت نام گره است، نه تزئین ظاهری. اگر سند با xmlns="urn:shop" ساخته شده باشد، مسیر /root/item بدون معرفی همان Namespace معمولاً نتیجه‌ای ندارد. می‌توان Namespace را داخل XQuery با declare namespace تعریف کرد یا برای Queryهای خواناتر از WITH XMLNAMESPACES بهره گرفت.

مدل اجرای XQuery در SQL Server

عبارت XQuery یک توالی از Itemها تولید می‌کند. توالی ممکن است خالی، تک‌عضوی یا چندعضوی باشد و Item می‌تواند گره یا مقدار اتمی باشد. این مفهوم علت بسیاری از تفاوت‌های متدها است: exist() فقط خالی بودن توالی را می‌سنجد، value() یک مقدار اتمی تک می‌خواهد، query() توالی را به XML برمی‌گرداند و nodes() برای گره‌های توالی Rowset می‌سازد.

SQL Server از Static Typing استفاده می‌کند. بنابراین موتور پیش از مشاهده داده واقعی بررسی می‌کند که عبارت از نظر نوع می‌تواند چند مقدار بدهد یا نه. مسیرهایی که از نظر انسان فقط یک نتیجه دارند ممکن است برای موتور چندمقداری باشند؛ به همین دلیل الگوی پرکاربرد (/order/@id)[1] اهمیت دارد. افزودن [1] نباید راهی برای پنهان کردن چند داده واقعی باشد؛ اگر همه گره‌ها مهم‌اند باید nodes() انتخاب شود.

دو تابع sql:variable() و sql:column() مرز میان T-SQL و XQuery را کنترل‌شده عبور می‌دهند. اولی مقدار متغیر SQL و دومی مقدار ستون ردیف جاری را در XQuery قابل استفاده می‌کند. این روش از ساخت رشته XQuery با الحاق ورودی جلوگیری می‌کند، نوع را بهتر حفظ می‌کند و Query را برای بررسی امنیت و نگهداری شفاف‌تر نگه می‌دارد.

معرفی و انتخاب پنج متد اصلی

value()؛ استخراج مقدار اسکالر از XML

متد value() یک مقدار اتمی و تکی را با XQuery از ستون یا متغیر xml می‌خواند و آن را به نوع داده SQL درخواستی تبدیل می‌کند. در XQuery تایپ ایستا اعمال می‌شود و حتی اگر از نظر داده فقط یک گره وجود داشته باشد، موتور معمولاً به پسوند [1] نیاز دارد.

مطالعه مقاله تخصصی value() با ده مثال اجرایی

query()؛ بازیابی قطعه XML با XQuery

متد query() نتیجه یک عبارت XQuery را به شکل یک مقدار xml بدون نوع برمی‌گرداند و برای انتخاب، بازسازی یا شکل‌دهی یک قطعه XML مناسب است. query() برای بازگرداندن گره یا قطعه XML طراحی شده است و جای value() برای اسکالر را نمی‌گیرد.

مطالعه مقاله تخصصی query() با ده مثال اجرایی

exist()؛ بررسی وجود گره یا نتیجه XQuery

متد exist() بررسی می‌کند آیا عبارت XQuery توالی غیرخالی تولید می‌کند و برای Predicateها، کنترل عناصر اختیاری و فیلتر اسناد XML مناسب است. exist() مقدار منطقی داخل توالی را تفسیر نمی‌کند؛ exist('false()') نیز 1 است چون یک Item بولی در نتیجه وجود دارد.

مطالعه مقاله تخصصی exist() با ده مثال اجرایی

nodes()؛ تبدیل گره‌های XML به ردیف‌های رابطه‌ای

متد nodes() یک Rowset از کپی‌های منطقی گره‌های انتخاب‌شده می‌سازد و پل اصلی میان ساختار سلسله‌مراتبی XML و پردازش رابطه‌ای SQL Server است. nodes() معمولاً با CROSS APPLY یا OUTER APPLY روی ستون XML جدول استفاده می‌شود.

مطالعه مقاله تخصصی nodes() با ده مثال اجرایی

modify()؛ ویرایش داده XML با XML DML

متد modify() با زبان XML DML یک تغییر insert، delete یا replace value of را روی مقدار xml انجام می‌دهد و فقط در SET دستور UPDATE یا روی متغیر xml قابل استفاده است. insert می‌تواند گره را as first، as last، before یا after مقصد درج کند.

مطالعه مقاله تخصصی modify() با ده مثال اجرایی

طراحی مدل داده: XML یا رابطه‌ای؟

XML زمانی ارزشمند است که ساختار واقعاً سلسله‌مراتبی، متغیر یا پیام‌محور باشد؛ برای نمونه Payload یکپارچه‌سازی، تنظیمات با شاخه‌های اختیاری یا نسخه خام یک سند بیرونی. اگر مقدارهایی مانند CustomerID، CreatedDate و Status در بیشتر Joinها و Filterها حضور دارند، نگهداری آن‌ها فقط داخل XML معمولاً هزینه بیشتری دارد. راهکار ترکیبی، یعنی ستون‌های رابطه‌ای برای کلیدهای پرتکرار و XML برای جزئیات متغیر، در بسیاری از سامانه‌ها تعادل مناسبی ایجاد می‌کند.

تکرار یک مقدار هم در ستون رابطه‌ای و هم در XML خطر ناسازگاری دارد. باید منبع حقیقت مشخص، مسیر Update واحد و Constraint یا کنترل برنامه‌ای تعریف شود. اگر مقدار رابطه‌ای مشتق‌شده از XML است، فرایند ورود داده باید در Transaction آن را استخراج کند. اگر XML صرفاً نسخه آرشیوی پیام است، بهتر است Immutable باقی بماند و اصلاحات کسب‌وکاری در جداول رابطه‌ای ثبت شوند.

برای اسناد حساس، امنیت در سطح ستون و ردیف کافی نیست؛ ممکن است یک سند شامل داده‌ای باشد که همه مصرف‌کنندگان مجاز به مشاهده آن نیستند. query() می‌تواند خروجی حداقلی بسازد، اما کنترل دسترسی باید در طراحی View، Stored Procedure و مجوزها اعمال شود. حذف موقت داده با modify() روی اصل سند، جای سیاست امنیتی و Audit را نمی‌گیرد.

ایندکس‌های XML و روش سنجش کارایی

Primary XML Index نمایش داخلی گره‌ها را برای ستون XML پایدار می‌کند و پیش‌نیاز ایندکس‌های ثانویه است. PATH Index برای جست‌وجوی مسیر و exist()، VALUE Index برای جست‌وجوی مقادیر بدون مسیر ثابت و PROPERTY Index برای بازیابی Propertyهای متعدد از یک شیء معمولاً کاندید هستند؛ اما نام ایندکس تضمین نمی‌کند که برای Query خاص شما مفید باشد.

هر XML Index فضای ذخیره‌سازی، زمان ساخت، هزینه Backup و سربار Insert و Update دارد. modify() روی ستونی با چند ایندکس ممکن است بسیار گران‌تر شود. بنابراین ابتدا Baseline شامل مدت، CPU، Logical Reads، Actual Rows، Memory Grant و حجم لاگ ثبت کنید؛ سپس فقط یک تغییر اعمال و دوباره همان workload را با پارامترهای نماینده اجرا کنید.

SET STATISTICS IO,TIME ON برای آزمایش محلی، Actual Execution Plan برای مشاهده XML Reader و Applyها، Query Store برای مقایسه تاریخی Plan و Extended Events برای رخدادهای هدفمند مفیدند. تست باید Warm Cache و Cold Cache را آگاهانه جدا کند و همزمانی واقعی را در نظر بگیرد؛ نتیجه یک اجرای تک‌کاربره روی لپ‌تاپ جای آزمون ظرفیت محیط تولید نیست.

مثال‌های ترکیبی و کاربردی

مثال 1: خواندن شناسه و آزمون وضعیت

شناسه با value() استخراج و وضعیت با exist() آزموده می‌شود.

DECLARE @x xml=N'<order id="15" status="open" />';
SELECT @x.value('(/order/@id)[1]','int') AS ID,
       @x.exist('/order[@status="open"]') AS IsOpen;

نکته کاربردی: هر متد بر اساس شکل خروجی انتخاب شده است.

مثال 2: خردکردن خطوط سفارش

nodes() ردیف می‌سازد و value() ستون‌های هر ردیف را استخراج می‌کند.

DECLARE @x xml=N'<o><l sku="A" qty="2"/><l sku="B" qty="3"/></o>';
SELECT X.N.value('(@sku)[1]','nvarchar(10)') AS SKU,
       X.N.value('(@qty)[1]','int') AS Qty
FROM @x.nodes('/o/l') AS X(N);

نکته کاربردی: این الگو پایه Shredding رابطه‌ای است.

مثال 3: ساخت نمای کم‌حجم

query() فقط داده مجاز و ضروری را در خروجی تازه قرار می‌دهد.

DECLARE @x xml=N'<u><name>مریم</name><token>x</token><city>اهواز</city></u>';
SELECT @x.query('<profile>{/u/name,/u/city}</profile>') AS PublicProfile;

نکته کاربردی: ساخت خروجی حداقلی حجم و افشای داده را کم می‌کند.

مثال 4: تغییر شرطی وضعیت

exist() شرط تغییر و modify() عمل نوشتن را انجام می‌دهد.

DECLARE @x xml=N'<task><state>new</state></task>';
IF @x.exist('/task/state[text()="new"]')=1
    SET @x.modify('replace value of (/task/state/text())[1] with "done"');
SELECT @x;

نکته کاربردی: شرط صریح از Update بی‌اثر یا اشتباه جلوگیری می‌کند.

مثال 5: پردازش Namespace

Namespace یک‌بار تعریف و سپس برای استخراج چند گره استفاده می‌شود.

DECLARE @x xml=N'<s:shop xmlns:s="urn:shop"><s:item id="2"/></s:shop>';
WITH XMLNAMESPACES('urn:shop' AS s)
SELECT X.N.value('(@id)[1]','int') AS ItemID
FROM @x.nodes('/s:shop/s:item') AS X(N);

نکته کاربردی: تعریف متمرکز Namespace خوانایی را بالا می‌برد.

مثال 6: فیلتر کارا پیش از Shredding

شرط رابطه‌ای و XML پیش از nodes() دامنه را محدود می‌کنند.

DECLARE @T table(ID int, Active bit, Doc xml);
INSERT INTO @T VALUES(1,1,N'<r><n k="x"/></r>'),(2,0,N'<r><n k="x"/></r>');
SELECT T.ID, X.N.query('.') AS NodeXml
FROM @T AS T
CROSS APPLY T.Doc.nodes('/r/n[@k="x"]') AS X(N)
WHERE T.Active=1;

نکته کاربردی: فیلتر زودهنگام تعداد ردیف‌های میانی را کنترل می‌کند.

خطاهای رایج و عیب‌یابی

نتیجه خالی را فوراً نبود داده فرض نکنید. ابتدا Namespace، بزرگی و کوچکی حروف، Context جاری و مسیر نسبی یا مطلق را بررسی کنید. یک نمونه حداقلی از XML مسئله‌دار بسازید و XQuery را جدا اجرا کنید. در خطای singleton، مشخص کنید نیاز واقعی یک مقدار است یا مجموعه؛ سپس [1] یا nodes() را آگاهانه انتخاب کنید.

خطاهای تبدیل value() باید با مقدار خام و SQLType مقصد بازتولید شوند. داده عددی با جداکننده محلی، تاریخ غیر ISO و متن بلندتر از نوع مقصد نمونه‌های رایج‌اند. پیش از تبدیل می‌توان قرارداد XML را با Schema یا کنترل‌های ورودی سخت‌گیرانه‌تر کرد. TRY_CONVERT بیرون از value() همیشه خطای داخل XQuery یا singleton را خنثی نمی‌کند.

در مشکل کارایی، فقط به درصد هزینه گرافیکی Plan تکیه نکنید. Actual Row و Estimated Row، تعداد اجرای اپراتور، Spill، Memory Grant و زمان CPU را ثبت کنید. در nodes() افزایش ضربی ردیف‌ها و در modify() حجم لاگ و نگهداری XML Index اهمیت ویژه دارند.

سؤالات مصاحبه تخصصی

1. چرا value() اغلب به [1] نیاز دارد و این موضوع چه ارتباطی با Static Typing دارد؟
2. تفاوت SQL NULL، توالی خالی و XML خالی در متدهای XML چیست؟
3. چه زمانی OUTER APPLY را به CROSS APPLY در کنار nodes() ترجیح می‌دهید؟
4. چرا exist(false()) مقدار 1 می‌دهد و روش درست آزمون شرط چیست؟
5. چه معیارهایی برای انتخاب PATH، VALUE یا PROPERTY XML Index اندازه‌گیری می‌کنید؟
6. چگونه تغییر چندمرحله‌ای modify() را از نظر Transaction، Audit و رشد Log ایمن می‌کنید؟

سؤالات متداول

۱. متدهای XML در SQL Server چه مسئله‌ای را حل می‌کنند؟

این متدها اجازه می‌دهند مقدار اسکالر بخوانیم، قطعه XML بسازیم، وجود گره را بررسی کنیم، مجموعه گره‌ها را به ردیف تبدیل کنیم و خود سند را تغییر دهیم.

۲. برای شروع یادگیری کدام متد مناسب‌تر است؟

ابتدا value() و exist() را بیاموزید، سپس nodes() را برای Shredding و query() را برای ساخت قطعه تمرین کنید؛ modify() به دلیل اثر نوشتن باید پس از درک Transaction مطالعه شود.

۳. آیا نگهداری XML در SQL Server از نظر تجاری منطقی است؟

برای پیام‌ها و بخش‌های نیمه‌ساخت‌یافته می‌تواند منطقی باشد، ولی داده‌های پرتکرار در Join و گزارش معمولاً در مدل رابطه‌ای هزینه کمتری دارند. تصمیم باید با workload واقعی گرفته شود.

۴. چه خدماتی برای بهبود سامانه‌های XML محور مفید است؟

بازبینی مدل داده، تحلیل Query Store، طراحی XML Schema Collection، انتخاب XML Index و آموزش تیم توسعه بیشترین ارزش را دارند؛ دامنه کار باید با Baseline قابل اندازه‌گیری تعریف شود.

۵. تفاوت value()، query() و nodes() چیست؟

value() یک اسکالر SQL می‌دهد، query() یک مقدار xml برمی‌گرداند و nodes() برای هر گره انتخاب‌شده یک ردیف Context تولید می‌کند. نوع مصرف‌کننده تعیین‌کننده انتخاب است.

۶. برای طراحی یک راهکار XML از کجا شروع کنیم؟

نمونه اسناد، Namespace، سقف حجم، نسبت خواندن به نوشتن و Queryهای حیاتی را جمع‌آوری کنید. سپس مدل XML و رابطه‌ای را با معیارهای مشترک آزمایش کنید.

۷. رایج‌ترین خطای توابع XML چیست؟

اشتباه در Namespace و singleton رایج است. مسیر را روی یک نمونه کوچک اجرا کنید، [1] را آگاهانه به کار ببرید و نتیجه خالی را فوراً نبود داده فرض نکنید.

۸. Performance توابع XML چگونه سنجیده می‌شود؟

زمان CPU، Logical Reads، تعداد ردیف پس از APPLY، اندازه XML Index، Memory Grant و زمان نوشتن را پیش و پس از تغییر با Query Store و Actual Plan مقایسه کنید.

۹. Best Practice اصلی چیست؟

XML را برای بخش واقعاً سلسله‌مراتبی نگه دارید، کلیدهای جست‌وجوی پرتکرار را رابطه‌ای کنید، Namespace را مستند کنید و ایندکس را فقط پس از اندازه‌گیری بسازید.

۱۰. سازگاری نسخه‌ای متدهای XML چگونه است؟

هسته متدها از SQL Server 2005 وجود دارد، اما Optimizer، Cardinality Estimation و امکانات پایش در نسخه‌های جدید تغییر کرده‌اند؛ آزمون روی Compatibility Level مقصد ضروری است.

چک‌لیست نهایی

• نوع خروجی موردنیاز و متد مناسب مشخص شده است.
• Namespace و قرارداد XML مستند و تست شده‌اند.
• NULL، گره غایب، چند گره و مقدار نامعتبر پوشش تست دارند.
• فیلترهای رابطه‌ای پیش از پردازش سنگین XML اعمال شده‌اند.
• Baseline کارایی و Plan پیش از ساخت XML Index ثبت شده است.
• مجوز، Audit، Transaction و رشد Log برای modify() بررسی شده‌اند.

جمع‌بندی و مسیر مطالعه

پنج متد XML یک خانواده واحدند اما نقش‌های قابل جایگزینی ندارند. کیفیت طراحی از پرسش ساده «خروجی من اسکالر، XML، بولی، Rowset یا تغییر پایدار است؟» شروع می‌شود. پس از انتخاب متد، Static Typing، Namespace، NULL و Cardinality را بررسی و سپس با داده نماینده کارایی را اندازه‌گیری کنید.

برای ادامه، مقاله‌های تخصصی را به ترتیب نیاز پروژه مطالعه کنید: آموزش کامل متد value()، آموزش کامل متد query()، آموزش کامل متد exist()، آموزش کامل متد nodes()، آموزش کامل متد modify(). هر مقاله ده مثال مستقل، خطاهای رایج، نکات Performance و Best Practiceهای همان متد را ارائه می‌کند.