مقدمه

تقریباً هر سامانه SQL Server با چند شکل از یک واقعیت روبه‌رو می‌شود: مبلغی که به‌صورت متن رسیده، تاریخی که قالب آن به کشور فرستنده وابسته است، شناسه‌ای که باید برای نمایش رشته شود یا ستونی قدیمی که نوع آن با معنای امروزی داده هماهنگ نیست. توابع تبدیل پل میان این نمایش‌ها هستند، اما انتخاب اشتباه آن‌ها می‌تواند به خطای تبدیل، قطع متن، گرد شدن مبلغ، تاریخ اشتباه یا Plan اجرایی ضعیف منجر شود.

SQL Server شش تابع اصلی برای این حوزه در اختیار ما می‌گذارد: CAST و CONVERT برای تبدیل قطعی، TRY_CAST و TRY_CONVERT برای شکست آرام، و PARSE و TRY_PARSE برای تفسیر متن بر اساس Cultureهای .NET. این توابع شبیه به هم به نظر می‌رسند، ولی هدف، نحو، رفتار خطا، قابلیت Style و هزینه اجرایی آن‌ها یکسان نیست. این مقاله نقشه تصمیم کامل و مقاله‌های مستقل هر تابع را در اختیار شما قرار می‌دهد.

تبدیل صریح باید از مدل داده آغاز شود. پیش از نوشتن Query بپرسید مقدار واقعاً عدد است یا متن، آیا رشته باید یونیکد باشد، چند رقم صحیح و اعشاری لازم است، تاریخ فقط روز را نگه می‌دارد یا زمان و Offset هم اهمیت دارد، و در شکست ورودی چه کسی مسئول اصلاح است. پاسخ این پرسش‌ها نوع مقصد و تابع مناسب را تعیین می‌کند.

قاعده کلیدی: اگر داده را کنترل می‌کنید، آن را از ابتدا با نوع درست ذخیره کنید. تابع تبدیل ابزار مرزهای ورودی، مهاجرت و نمایش است و نباید به پوششی دائمی برای طراحی نادرست ستون تبدیل شود.

دسترسی سریع به آموزش هر تابع

• آموزش کامل CAST؛ تبدیل استاندارد نوع داده
• آموزش کامل CONVERT؛ تبدیل نوع با پشتیبانی از Style
• آموزش کامل TRY_CAST؛ تبدیل امن با خروجی NULL
• آموزش کامل TRY_CONVERT؛ تبدیل امن همراه Style
• آموزش کامل PARSE؛ تبدیل فرهنگی متن با .NET
• آموزش کامل TRY_PARSE؛ تبدیل فرهنگی امن متن

مبانی تبدیل نوع داده در SQL Server

هر عبارت در SQL Server یک نوع داده دارد و موتور برای ترکیب دو نوع متفاوت از قواعد تقدم نوع استفاده می‌کند. در تبدیل ضمنی، SQL Server خودش سمت و نوع تبدیل را انتخاب می‌کند؛ این انتخاب گاهی درست است، اما ممکن است رشته نامعتبر را به عدد تبدیل کند و خطا دهد یا تابع CONVERT_IMPLICIT را روی ستون ایندکس‌شده قرار دهد. تبدیل صریح قصد برنامه‌نویس را آشکار و رفتار را قابل تست می‌کند.

نوع مقصد فقط یک نام نیست. در decimal باید precision و scale را تعیین کرد؛ در varchar و nvarchar طول مهم است؛ در datetime2 دقت بخش کسری و در datetimeoffset Offset جزئی از مقدار است. انتخاب مقصد کوچک ممکن است سرریز یا قطع داده بسازد و مقصد بیش از حد بزرگ نیز حافظه، ایندکس و تخمین‌ها را تحت تأثیر قرار می‌دهد.

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

انتخاب تابع مناسب

CAST گزینه استاندارد و خوانا برای تبدیل معمولی است. CONVERT در SQL Server علاوه بر تبدیل، آرگومان Style دارد و برای خواندن یا نمایش تاریخ، زمان، money و باینری مفید است. اگر داده از قرارداد معتبر می‌آید و شکست باید فوراً آشکار شود، نسخه‌های قطعی رفتار مناسبی دارند.

TRY_CAST و TRY_CONVERT برای ورودی کنترل‌نشده طراحی مقاوم‌تری می‌سازند، زیرا بیشتر شکست‌های رایج را به NULL تبدیل می‌کنند. با این حال NULL نتیجه پایان کار نیست. باید میان NULL اصلی و شکست تبدیل فرق گذاشت، تعداد خطاها را ثبت کرد و ردیف Reject را برای اصلاح نگه داشت. تبدیل صریحاً ممنوع نیز حتی در خانواده TRY ممکن است خطا بدهد.

PARSE و TRY_PARSE زمانی مطرح می‌شوند که معنای رشته به Culture وابسته است: برای نمونه 1.234,50 در de-DE و 1,234.50 در en-US یک مبلغ واحد را نمایش می‌دهند. این توابع از CLR و قواعد .NET استفاده می‌کنند و برای تبدیل ساده ISO انتخاب نخست نیستند. روی حجم بالا، نرمال‌سازی در سرویس ورودی یا Staging معمولاً بهتر است.

تابع CAST در SQL Server

CAST تابع استاندارد SQL برای تبدیل صریح یک عبارت از یک نوع داده به نوع دیگر است. زمانی از آن استفاده می‌کنیم که تبدیل ضمنی SQL Server کافی، روشن یا قابل اعتماد نباشد. این تابع خوانایی قصد برنامه‌نویس را بالا می‌برد و در بیشتر سامانه‌های پایگاه داده با نحوی مشابه در دسترس است.

این تابع برای «تبدیل استاندارد نوع داده» در مجموعه Conversion Functions قرار می‌گیرد. پیش از استفاده، نوع مقصد، رفتار ورودی خراب و محل اجرای تبدیل در Plan را مشخص کنید؛ سپس نمونه‌های مرزی را در محیط آزمایشی اجرا کنید.

آموزش کامل تابع CAST با ۱۰ مثال مستقل و خروجی نمونه

تابع CONVERT در SQL Server

CONVERT تابع اختصاصی و پرکاربرد SQL Server برای تبدیل صریح نوع داده است. تفاوت مهم آن با CAST، آرگومان اختیاری style است که شکل خواندن یا نمایش تاریخ، زمان، عدد پولی، float و داده باینری را کنترل می‌کند. این قابلیت در گزارش‌ها و یکپارچه‌سازی سامانه‌های قدیمی ارزش زیادی دارد.

این تابع برای «تبدیل نوع با پشتیبانی از Style» در مجموعه Conversion Functions قرار می‌گیرد. پیش از استفاده، نوع مقصد، رفتار ورودی خراب و محل اجرای تبدیل در Plan را مشخص کنید؛ سپس نمونه‌های مرزی را در محیط آزمایشی اجرا کنید.

آموزش کامل تابع CONVERT با ۱۰ مثال مستقل و خروجی نمونه

تابع TRY_CAST در SQL Server

TRY_CAST همان الگوی نحوی CAST را دارد، اما در بیشتر تبدیل‌های ناموفق به جای ایجاد خطا مقدار NULL برمی‌گرداند. این رفتار برای داده‌های واردشده از فایل، فرم کاربر، API یا سامانه‌های قدیمی بسیار مفید است. با این حال، تبدیل‌هایی که اصولاً از سوی SQL Server مجاز نیستند همچنان می‌توانند خطا ایجاد کنند.

این تابع برای «تبدیل امن با خروجی NULL» در مجموعه Conversion Functions قرار می‌گیرد. پیش از استفاده، نوع مقصد، رفتار ورودی خراب و محل اجرای تبدیل در Plan را مشخص کنید؛ سپس نمونه‌های مرزی را در محیط آزمایشی اجرا کنید.

آموزش کامل تابع TRY_CAST با ۱۰ مثال مستقل و خروجی نمونه

تابع TRY_CONVERT در SQL Server

TRY_CONVERT نسخه مقاوم CONVERT است و هم‌زمان دو قابلیت مهم ارائه می‌کند: بازگرداندن NULL در شکست‌های رایج تبدیل و پذیرش آرگومان style. این ترکیب برای تشخیص تاریخ‌هایی با قالب معلوم، پاک‌سازی داده‌های متنی و جلوگیری از شکست دسته‌ای رکوردها مناسب است.

این تابع برای «تبدیل امن همراه Style» در مجموعه Conversion Functions قرار می‌گیرد. پیش از استفاده، نوع مقصد، رفتار ورودی خراب و محل اجرای تبدیل در Plan را مشخص کنید؛ سپس نمونه‌های مرزی را در محیط آزمایشی اجرا کنید.

آموزش کامل تابع TRY_CONVERT با ۱۰ مثال مستقل و خروجی نمونه

تابع PARSE در SQL Server

PARSE یک رشته را با استفاده از زیرساخت .NET و قواعد فرهنگ زبانی مشخص به عدد یا تاریخ و زمان تبدیل می‌کند. وقتی جداکننده اعشار، نماد پول یا ترتیب روز و ماه به Culture وابسته است، PARSE از CAST و CONVERT گویاتر است. این تابع فقط مقصدهای عددی و تاریخ‌وزمان را پشتیبانی می‌کند و هزینه بیشتری دارد.

این تابع برای «تبدیل فرهنگی متن با .NET» در مجموعه Conversion Functions قرار می‌گیرد. پیش از استفاده، نوع مقصد، رفتار ورودی خراب و محل اجرای تبدیل در Plan را مشخص کنید؛ سپس نمونه‌های مرزی را در محیط آزمایشی اجرا کنید.

آموزش کامل تابع PARSE با ۱۰ مثال مستقل و خروجی نمونه

تابع TRY_PARSE در SQL Server

TRY_PARSE نسخه امن‌تر PARSE برای رشته‌های عددی و تاریخی وابسته به Culture است. اگر متن مطابق قواعد فرهنگ انتخاب‌شده نباشد، معمولاً NULL برمی‌گرداند و پردازش سایر ردیف‌ها ادامه می‌یابد. این تابع همچنان از CLR استفاده می‌کند؛ بنابراین برای تبدیل‌های ساده یا حجم بسیار زیاد، نخست گزینه‌های بومی SQL Server را بررسی کنید.

این تابع برای «تبدیل فرهنگی امن متن» در مجموعه Conversion Functions قرار می‌گیرد. پیش از استفاده، نوع مقصد، رفتار ورودی خراب و محل اجرای تبدیل در Plan را مشخص کنید؛ سپس نمونه‌های مرزی را در محیط آزمایشی اجرا کنید.

آموزش کامل تابع TRY_PARSE با ۱۰ مثال مستقل و خروجی نمونه

تبدیل تاریخ، زمان، UTC و Offset

تاریخ متنی یکی از پرخطرترین ورودی‌هاست. رشته 07/08/2026 بدون قرارداد می‌تواند دو روز متفاوت باشد. برای ورودی‌های ماشینی قالب ISO 8601 و برای قالب‌های مشخص Style صریح CONVERT یا TRY_CONVERT را انتخاب کنید. اگر نام ماه یا جداکننده‌ها به زبان و کشور وابسته‌اند، PARSE یا TRY_PARSE همراه Culture معتبر معنا پیدا می‌کند.

date فقط روز تقویمی را نگه می‌دارد؛ datetime2 تاریخ و زمان را با دقت قابل تنظیم حفظ می‌کند؛ datetimeoffset علاوه بر آن Offset را نیز دارد. تبدیل datetimeoffset به datetime2 می‌تواند اطلاعات Offset را حذف کند. همچنین تبدیل مقدار به varchar با Style، زمان محلی را به UTC تبدیل نمی‌کند. تبدیل منطقه زمانی باید با منطق مشخصی مانند AT TIME ZONE و قواعد منطقه انجام شود.

در سامانه توزیع‌شده بهتر است لحظه رویداد با Offset یا UTC ذخیره و منطقه زمانی کسب‌وکاری جداگانه نگهداری شود. نمایش برای کاربر می‌تواند بر اساس منطقه انتخابی انجام گیرد. تبدیل متن تاریخ در زمان ورود باید قرارداد، Culture، دقت ثانیه و رفتار ساعت تابستانی را پوشش دهد.

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

مثال 1: انتخاب CAST برای تبدیل استاندارد

در محاسبه درصد، تبدیل یکی از عددهای صحیح به decimal مانع حذف بخش اعشاری می‌شود. این سناریو نمونه‌ای از کاربرد روشن و قابل‌حمل CAST در منطق تحلیلی است.

DECLARE @Done int = 43, @All int = 80;
    SELECT CAST(@Done AS decimal(9,2)) / NULLIF(@All,0) * 100 AS DonePercent;

نکته کاربردی: تبدیل را پیش از تقسیم انجام دهید و نوع decimal را مطابق دقت موردنیاز گزارش انتخاب کنید.

مثال 2: انتخاب CONVERT برای خروجی تاریخ ISO

وقتی خروجی متنی تاریخ باید قالبی قطعی داشته باشد، CONVERT و Style شماره 126 قصد را دقیق بیان می‌کنند. مقدار datetime2 اصلی برای محاسبات حفظ می‌شود.

DECLARE @OccurredAt datetime2(0) = '2026-07-19T18:20:00';
    SELECT CONVERT(varchar(19), @OccurredAt, 126) AS ApiDateTime;

نکته کاربردی: در قرارداد API منطقه زمانی و Offset را جداگانه مشخص کنید؛ تبدیل متنی به‌تنهایی زمان محلی را به UTC تبدیل نمی‌کند.

مثال 3: پاک‌سازی عدد با TRY_CAST

یک فهرست متنی می‌تواند هم عدد سالم و هم مقدار خراب داشته باشد. TRY_CAST اجازه می‌دهد مقدار استاندارد و وضعیت کیفیت در یک Query دیده شوند.

DECLARE @Raw TABLE (Id int, ValueText varchar(20));
    INSERT INTO @Raw VALUES (1,'18'),(2,'unknown');
    
    SELECT Id, TRY_CAST(ValueText AS int) AS ValueInt,
           CASE WHEN TRY_CAST(ValueText AS int) IS NULL THEN N'نیازمند بررسی' ELSE N'معتبر' END AS Status
    FROM @Raw;

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

مثال 4: اعتبارسنجی تاریخ با TRY_CONVERT و Style

این مثال دو رشته با قالب بریتانیایی را آزمایش می‌کند. یکی معتبر است و دیگری روز ناممکن دارد؛ Query بدون توقف هر دو نتیجه را گزارش می‌دهد.

DECLARE @Dates TABLE (TextValue varchar(20));
    INSERT INTO @Dates VALUES ('19/07/2026'),('31/04/2026');
    
    SELECT TextValue, TRY_CONVERT(date, TextValue, 103) AS CleanDate
    FROM @Dates;

نکته کاربردی: Style مشخص از وابستگی به تنظیم زبان Session جلوگیری می‌کند و خطای تقویمی نیز واقعاً بررسی می‌شود.

مثال 5: تبدیل عدد Culture محور با PARSE

مبلغ آلمانی از نقطه برای هزارگان و ویرگول برای اعشار استفاده می‌کند. PARSE قواعد de-DE را اعمال و یک decimal مستقل از Culture می‌سازد.

SELECT PARSE('12.345,67' AS decimal(12,2) USING 'de-DE') AS NormalizedAmount;

نکته کاربردی: PARSE برای معنای فرهنگی واقعی مناسب است؛ برای رشته ISO یا عدد ساده از توابع بومی کم‌هزینه‌تر استفاده کنید.

مثال 6: مسیر مقاوم چندفرهنگی با TRY_PARSE

در ورودی بین‌المللی، یک مقدار خراب نباید همه دسته را متوقف کند. TRY_PARSE مقدار سالم را تبدیل و برای متن نامعتبر NULL تولید می‌کند.

DECLARE @Feed TABLE (Id int, AmountText nvarchar(30));
    INSERT INTO @Feed VALUES (1,N'1,250.00'),(2,N'bad data');
    
    SELECT Id, TRY_PARSE(AmountText AS decimal(12,2) USING 'en-US') AS Amount
    FROM @Feed;

نکته کاربردی: خروجی NULL را با شمارنده خطا، جدول Reject و مالک اصلاح داده همراه کنید تا مقاومت سیستم به پنهان شدن مشکل منجر نشود.

طراحی فرآیند پاک‌سازی و ETL

یک فرآیند ورودی حرفه‌ای دست‌کم چهار جزء دارد: مقدار خام، متادیتای قالب یا Culture، مقدار استاندارد و وضعیت اعتبارسنجی. ردیف سالم به مدل نهایی می‌رود و ردیف ناسالم با علت Reject باقی می‌ماند. حذف بی‌صدای NULLهای حاصل از TRY می‌تواند جمع مالی و شاخص مدیریتی را ناقص نشان دهد، بنابراین نرخ شکست باید بخشی از خروجی Pipeline باشد.

قواعد اعتبارسنجی را لایه‌بندی کنید. ابتدا وجود مقدار و طول را بسنجید، سپس تبدیل نوع را انجام دهید و پس از آن محدودیت کسب‌وکار مانند مثبت بودن مبلغ یا قرار گرفتن تاریخ در بازه مجاز را اعمال کنید. تبدیل موفق فقط می‌گوید رشته در نوع مقصد جا می‌شود؛ درباره مجاز بودن آن برای سفارش، قرارداد یا حسابداری داوری نمی‌کند.

برای مهاجرت، نمونه‌برداری کافی نیست. پروفایل کامل داده، بیشینه طول، دامنه عدد، توزیع Culture و درصد شکست را اندازه بگیرید. اجرای آزمایشی باید قابل بازگشت باشد و تعداد ردیف منبع، سالم و Reject با هم تطبیق داده شوند. در پروژه‌های حساس، جدول نگاشت خطا و گزارش روزانه کیفیت مسیر اصلاح را کوتاه می‌کند.

Performance، ایندکس و Query Plan

تبدیل روی یک ثابت یا پارامتر معمولاً کم‌هزینه است، ولی تبدیل روی هر ردیف جدول بزرگ می‌تواند CPU قابل توجهی مصرف کند. اگر تابع روی ستون ایندکس‌شده در WHERE یا JOIN قرار گیرد، موتور اغلب نمی‌تواند دامنه کلید را مستقیم جست‌وجو کند. نشانه این مشکل ممکن است Index Scan، هشدار CONVERT_IMPLICIT یا تفاوت نوع پارامتر و ستون باشد.

قاعده عملی این است که سمت کوچک‌تر و کنترل‌شده را به نوع سمت بزرگ‌تر تبدیل کنید. برای فیلتر روز روی datetime2 از بازه شروع شامل و پایان غیرشامل استفاده کنید. برای داده خام، مقدار پاک‌شده را هنگام ورود محاسبه و روی ستون استاندارد ایندکس ایجاد کنید. ستون محاسباتی Persisted نیز در بعضی طراحی‌ها مفید است، به شرط آنکه عبارت قطعی و هزینه نگهداری قابل قبول باشد.

PARSE و TRY_PARSE به CLR متکی‌اند و برای رشته Culture محور ساخته شده‌اند. جایگزین کردن همه CONVERTها با PARSE انعطاف ظاهری ایجاد می‌کند، اما روی حجم بالا هزینه دارد و امکان Remoting محدود است. معیار نهایی باید اندازه‌گیری Actual Plan، CPU، elapsed time و logical reads با داده نزدیک تولید باشد.

خطاهای رایج و راه پیشگیری

• تبدیل رشته تاریخ مبهم بدون ISO، Style یا Culture صریح.
• استفاده از varchar برای متن فارسی و فراموش کردن پیشوند N در Literal یونیکد.
• ننوشتن طول نوع متنی و پذیرفتن قطع شدن بی‌صدای خروجی.
• انتخاب decimal با precision و scale نامتناسب با مبلغ واقعی.
• اجرای CAST یا CONVERT روی ستون ایندکس‌شده در شرط پرتکرار.
• جایگزینی همه خروجی‌های NULL نسخه TRY با صفر و پنهان کردن داده خراب.
• استفاده از PARSE برای تبدیل ساده‌ای که به Culture نیاز ندارد.
• ذخیره مقدار قالب‌بندی‌شده به‌جای عدد یا تاریخ استاندارد.

پیشگیری با قرارداد داده آغاز می‌شود: نوع، طول، قالب، Culture، منطقه زمانی، رفتار خطا و مالک اصلاح باید مستند باشند. تست خودکار نیز باید داده سالم، خراب، NULL، سرریز، تاریخ مرزی، Unicode و حجم نزدیک تولید را پوشش دهد.

بهترین روش‌ها و چک‌لیست تصمیم

1. برای تبدیل معمولی و قابل‌حمل، CAST را از نقطه شروع بررسی کنید.
2. وقتی Style تاریخ، زمان یا باینری لازم است، CONVERT یا TRY_CONVERT را انتخاب کنید.
3. برای ورودی ناسالم از نسخه TRY همراه ثبت Reject استفاده کنید.
4. فقط برای معنای واقعی Culture به PARSE یا TRY_PARSE بروید.
5. نوع استاندارد را هنگام ورود ذخیره و قالب‌بندی را به لایه نمایش واگذار کنید.
6. پارامتر را به نوع ستون تبدیل کنید و Predicate را SARGable نگه دارید.
7. تبدیل زمان محلی، UTC و Offset را از قالب‌بندی متنی جدا بدانید.
8. Plan و نرخ شکست را پس از انتشار پایش کنید.

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

پرسش متداول 1: توابع تبدیل داده در SQL Server چه مسئله‌ای را حل می‌کنند؟

این توابع مقدار را از نوع مبدأ به نوع مقصد می‌برند تا مقایسه، محاسبه، ذخیره‌سازی یا نمایش با معنای درست انجام شود. تبدیل صریح از اتکا به اولویت نوع و تصمیم ضمنی موتور جلوگیری می‌کند.

پرسش متداول 2: چگونه نوع مقصد مناسب را انتخاب کنیم؟

دامنه مقدار، تعداد رقم صحیح و اعشاری، نیاز یونیکد، دقت تاریخ و طول متن را از قرارداد کسب‌وکار استخراج کنید. کوچک‌ترین نوع صرفاً زمانی خوب است که احتمال سرریز و قطع داده واقعاً کنترل شده باشد.

پرسش متداول 3: آموزش توابع تبدیل چه سود تجاری دارد؟

تبدیل نادرست می‌تواند مبلغ، تاریخ سررسید یا شاخص مدیریتی را عوض کند. آموزش کاربردی تیم، خطاهای تولید و هزینه اصلاح داده را کم و اعتماد به گزارش‌ها را بیشتر می‌کند.

پرسش متداول 4: بازبینی تبدیل‌ها در پروژه سازمانی چه ارزشی ایجاد می‌کند؟

بازبینی تخصصی SQL Server نقاط تبدیل ضمنی، شرط‌های غیر SARGable و داده‌های بی‌کیفیت را آشکار می‌کند. نتیجه می‌تواند Plan بهتر، SLA روشن‌تر برای ورودی و خطای عملیاتی کمتر باشد.

پرسش متداول 5: تفاوت خانواده CAST، CONVERT و PARSE چیست؟

CAST تبدیل استاندارد است؛ CONVERT قابلیت Style مخصوص SQL Server دارد؛ PARSE برای متن وابسته به Culture از .NET کمک می‌گیرد. پیشوند TRY در شکست‌های رایج به‌جای خطا NULL تولید می‌کند.

پرسش متداول 6: برای اصلاح تبدیل‌های یک سامانه موجود از کجا شروع کنیم؟

نمونه داده، DDL جدول‌ها، Queryهای پرتکرار، Plan اجرایی و خطاهای ثبت‌شده باید بررسی شوند. سپس می‌توان با مشاوره یا انجام پروژه، مهاجرت مرحله‌ای و تست بازگشت‌پذیر طراحی کرد.

پرسش متداول 7: رایج‌ترین خطا در تبدیل نوع داده چیست؟

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

پرسش متداول 8: توابع تبدیل چگونه بر Performance اثر می‌گذارند؟

تبدیل میلیون‌ها ردیف CPU مصرف می‌کند و تبدیل ستون در Predicate می‌تواند مانع Seek شود. PARSE نیز به‌دلیل CLR معمولاً سنگین‌تر است؛ تبدیل یک‌باره در Staging اغلب طراحی بهتری است.

پرسش متداول 9: Best Practice عمومی برای Conversion چیست؟

نوع درست را در مبدأ ذخیره کنید، ورودی خام و وضعیت خطا را نگه دارید، تبدیل را صریح و قطعی بنویسید و قالب‌بندی را به مرز نمایش منتقل کنید. تست NULL، سرریز، Culture و تاریخ مرزی را فراموش نکنید.

پرسش متداول 10: سازگاری نسخه‌ای این توابع چگونه است؟

CAST و CONVERT سابقه طولانی دارند؛ TRY_CAST، TRY_CONVERT، PARSE و TRY_PARSE از SQL Server 2012 ارائه شده‌اند. برای نسخه هدف، سطح Compatibility، CLR و امکان Remoting را در محیط آزمایشی کنترل کنید.

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

سؤال مصاحبه 1: Data Type Precedence چه ارتباطی با Conversion دارد؟

وقتی دو نوع متفاوت در یک عبارت حضور دارند، SQL Server معمولاً نوع با اولویت پایین‌تر را به نوع بالاتر تبدیل می‌کند. این تصمیم می‌تواند خطا یا CONVERT_IMPLICIT روی ستون بسازد؛ تبدیل صریح سمت درست رفتار را کنترل می‌کند.

سؤال مصاحبه 2: چرا TRY_CAST همیشه جای CAST را نمی‌گیرد؟

زیرا Fail-fast گاهی بخشی از قرارداد صحیح است و تبدیل‌های ممنوع همچنان ممکن است خطا دهند. افزون بر آن، NULL خروجی TRY بدون ثبت کیفیت می‌تواند خطا را از دید گزارش پنهان کند.

سؤال مصاحبه 3: چه زمانی PARSE بر TRY_CONVERT ترجیح دارد؟

وقتی رشته با قواعد Culture واقعی مانند نام ماه محلی، نماد پول یا جداکننده منطقه‌ای معنا دارد. برای قالب ثابت و معلوم، TRY_CONVERT همراه Style معمولاً بومی‌تر و سبک‌تر است.

سؤال مصاحبه 4: چگونه شرط تاریخ را SARGable می‌نویسید؟

به‌جای تبدیل ستون datetime به date، مرز شروع روز را شامل و شروع روز بعد را غیرشامل مقایسه می‌کنم. این الگو امکان استفاده از ایندکس زمانی را بهتر حفظ می‌کند.

سؤال مصاحبه 5: برای مهاجرت ستون متنی به عدد چه طرحی دارید؟

داده را در Staging پروفایل می‌کنم، با نسخه TRY مقدار سالم و Reject را جدا می‌کنم، دامنه کسب‌وکار را می‌سنجم، شمارش‌ها را تطبیق می‌دهم و پس از تست، ستون نهایی عددی و ایندکس مناسب را می‌سازم.

جمع‌بندی

انتخاب تابع تبدیل یک تصمیم نحوی ساده نیست؛ این انتخاب درباره کیفیت ورودی، معنای Culture، رفتار خطا، دقت نوع مقصد و مسیر اجرای Query اطلاعات می‌دهد. CAST و CONVERT برای مسیر قطعی، خانواده TRY برای ورودی مقاوم و خانواده PARSE برای متن Culture محور طراحی شده‌اند. بهترین طراحی داده استاندارد را زود تبدیل می‌کند، خطا را قابل مشاهده نگه می‌دارد و گزارش را از تبدیل تکراری آزاد می‌سازد.

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

• آموزش CAST در SQL Server؛ از مقدماتی تا Performance
• آموزش CONVERT در SQL Server؛ از مقدماتی تا Performance
• آموزش TRY_CAST در SQL Server؛ از مقدماتی تا Performance
• آموزش TRY_CONVERT در SQL Server؛ از مقدماتی تا Performance
• آموزش PARSE در SQL Server؛ از مقدماتی تا Performance
• آموزش TRY_PARSE در SQL Server؛ از مقدماتی تا Performance