مقدمه

تابع CAST یکی از ابزارهای مهم تبدیل داده در Microsoft SQL Server است. تبدیل نوع فقط تغییر ظاهر مقدار نیست؛ نوع مقصد بر مقایسه، دقت محاسبه، مرتب‌سازی، مصرف حافظه و امکان استفاده از ایندکس اثر می‌گذارد. در این راهنما از مثال ساده آغاز می‌کنیم و سپس سناریوهای پاک‌سازی داده، گزارش‌گیری، مدیریت NULL و بهینه‌سازی را بررسی می‌کنیم.

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

برای دیدن جایگاه این تابع در کنار پنج گزینه دیگر، راهنمای جامع توابع تبدیل داده در SQL Server را نیز مطالعه کنید. آن مقاله یک جدول تصمیم دارد و نشان می‌دهد چه زمانی تبدیل استاندارد، نسخه امن، Style یا Culture انتخاب مناسب‌تری است.

تعریف تابع CAST

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

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

نحو یا Syntax

-- Syntax
    CAST ( expression AS data_type [ ( length ) ] )

پارامترها

• expression: مقدار، ستون یا عبارتی که باید تبدیل شود.
• data_type: نوع مقصد مانند int، decimal، varchar، nvarchar، date یا datetime2.
• length: طول اختیاری برای نوع‌های متنی و باینری؛ بهتر است همیشه آگاهانه تعیین شود.

نوع خروجی و رفتار خطا

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

چه زمانی از CAST استفاده کنیم؟

این تابع برای تبدیل صریح و بدون نیاز به Style یا Culture مناسب است و قصد Query را برای نگهدارنده بعدی روشن می‌کند. اگر داده در اختیار شماست، اصلاح نوع ستون در طراحی پایگاه داده معمولاً بهتر از تکرار تبدیل در همه Queryها خواهد بود.

تبدیل را نزدیک مرزی انجام دهید که داده از متن یا سامانه خارجی وارد مدل استاندارد می‌شود. مقدار خام را برای حسابرسی حفظ کنید، مقدار تبدیل‌شده را در نوع درست بنویسید و وضعیت اعتبارسنجی را جدا نگه دارید. این الگو سبب می‌شود گزارش‌ها ساده‌تر، ایندکس‌ها مؤثرتر و مسئولیت کیفیت داده شفاف‌تر باشد.

در عملیات مالی، precision و scale را از قبل محاسبه کنید. در متن فارسی nvarchar و پیشوند N را به‌کار ببرید. برای تاریخ‌وزمان نیز میان date، datetime2 و datetimeoffset تفاوت بگذارید؛ تبدیل یک زمان محلی به متن، آن را خودکار به UTC تبدیل نمی‌کند و Offset باید در قرارداد سامانه مشخص باشد.

مثال‌های عملی

مثال 1: تبدیل متن عددی به عدد صحیح

در ورودی‌های متنی سالم، CAST مقدار رشته‌ای را به int تبدیل می‌کند تا محاسبات عددی به‌جای الحاق رشته انجام شوند. این مثال تفاوت نتیجه متنی و جمع عددی را روشن می‌کند.

SELECT CAST('125' AS int) + 25 AS FinalAmount;

نکته کاربردی: نوع مقصد را بر اساس دامنه واقعی داده انتخاب کنید؛ اگر عدد ممکن است از محدوده int بزرگ‌تر شود، bigint انتخاب مطمئن‌تری است.

مثال 2: تبدیل عدد اعشاری با دقت کنترل‌شده

برای مبالغ مالی باید precision و scale مقصد صریح باشند. در این نمونه SQL Server مقدار را تا دو رقم اعشار گرد می‌کند و نتیجه‌ای مناسب نمایش مبلغ می‌سازد.

SELECT CAST(12345.6789 AS decimal(12,2)) AS RoundedAmount;

نکته کاربردی: کوچک انتخاب‌کردن precision ممکن است خطای سرریز ایجاد کند؛ ظرفیت بخش صحیح و اعشاری را پیش از طراحی ستون محاسبه کنید.

مثال 3: تبدیل datetime2 به date در SELECT

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

DECLARE @CreatedAt datetime2(0) = '2026-07-19T14:35:20';
    SELECT CAST(@CreatedAt AS date) AS CreatedDate;

نکته کاربردی: این تبدیل مقدار تازه‌ای می‌سازد و داده ذخیره‌شده را تغییر نمی‌دهد؛ برای نگهداری ساعت، ستون اصلی را همچنان datetime2 نگه دارید.

مثال 4: تبدیل عددهای متنی جدول فروش

یک جدول موقت، مبلغ‌های متنی یک منبع قدیمی را شبیه‌سازی می‌کند. چون همه مقادیر سالم‌اند، CAST آن‌ها را به decimal تبدیل می‌کند و SUM جمع واقعی را به دست می‌آورد.

CREATE TABLE #Sales (AmountText varchar(20));
    INSERT INTO #Sales VALUES ('120.50'), ('79.50'), ('300.00');
    
    SELECT SUM(CAST(AmountText AS decimal(10,2))) AS TotalSales
    FROM #Sales;
    
    DROP TABLE #Sales;

نکته کاربردی: در داده تولیدی قبل از CAST قطعی، کیفیت ورودی را تضمین کنید؛ برای منبع ناسالم TRY_CAST انتخاب بهتری است.

مثال 5: فیلتر مبلغ‌های بزرگ در WHERE

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

DECLARE @Orders TABLE (OrderId int, AmountText varchar(20));
    INSERT INTO @Orders VALUES (1,'75'), (2,'100'), (3,'250');
    
    SELECT OrderId, AmountText
    FROM @Orders
    WHERE CAST(AmountText AS int) >= 100;

نکته کاربردی: اعمال تابع روی ستون در WHERE معمولاً استفاده مستقیم از ایندکس را دشوار می‌کند؛ اصلاح نوع ستون یا ستون محاسباتی ایندکس‌شده راه‌حل پایدارتر است.

مثال 6: ترکیب CAST با CONCAT برای ساخت پیام

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

DECLARE @TicketId int = 4821;
    SELECT CONCAT(N'شماره درخواست: ', CAST(@TicketId AS varchar(12))) AS MessageText;

نکته کاربردی: برای متن فارسی خروجی را با N شروع کنید و در صورت نیاز مقصد را nvarchar بگیرید تا نویسه‌های یونیکد از بین نروند.

مثال 7: بررسی رفتار CAST با NULL

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

DECLARE @Value varchar(20) = NULL;
    SELECT CAST(@Value AS int) AS ConvertedValue,
           COALESCE(CAST(@Value AS int), 0) AS DisplayValue;

نکته کاربردی: جایگزینی NULL با صفر یک تصمیم کسب‌وکاری است؛ آن را فقط زمانی انجام دهید که صفر واقعاً معادل نبود مقدار باشد.

مثال 8: مشاهده قطع شدن متن در طول مقصد

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

SELECT CAST('SQL Server Conversion' AS varchar(10)) AS ShortText;

نکته کاربردی: طول انواع متنی را همیشه صریح و بر اساس قرارداد داده تعیین کنید؛ پیش‌فرض‌های طول در بافت‌های مختلف SQL یکسان نیستند.

مثال 9: ساخت گزارش میانگین با تقسیم اعشاری

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

DECLARE @Completed int = 7, @Total int = 12;
    SELECT CAST(@Completed AS decimal(9,4)) / NULLIF(@Total,0) * 100 AS CompletionPercent;

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

مثال 10: روش SARGable برای فیلتر تاریخ

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

DECLARE @TargetDate date = '2026-07-19';
    
    SELECT OrderId, CreatedAt
    FROM dbo.Orders
    WHERE CreatedAt >= @TargetDate
      AND CreatedAt < DATEADD(day, 1, @TargetDate);

نکته کاربردی: در جدول واقعی، ایندکس روی CreatedAt می‌تواند این شرط بازه‌ای را به‌خوبی پشتیبانی کند؛ CAST را به سمت پارامتر منتقل کنید، نه ستون ایندکس‌شده.

NULL، داده مرزی و اعتبارسنجی

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

داده‌های مرزی شامل بزرگ‌ترین عدد مجاز، متن با طول دقیق مقصد، زمان‌های نزدیک تغییر روز، تاریخ ناممکن، نویسه‌های یونیکد و رشته دارای فاصله هستند. برای هرکدام تست خودکار بنویسید و نتیجه را در نسخه هدف SQL Server کنترل کنید. همچنین Collation، زبان Session و DATEFORMAT را در تست یکپارچگی نادیده نگیرید.

خطاهای رایج

• اعتماد به تبدیل ضمنی و نادیده گرفتن اولویت نوع‌های داده در عبارت یا Join.
• ننوشتن طول varchar یا nvarchar و بریده شدن خروجی در یکی از مسیرهای اجرا.
• انتخاب decimal با precision ناکافی و ایجاد سرریز یا گرد شدن ناخواسته.
• استفاده از تبدیل قطعی روی فایل یا ورودی کاربر بدون کنترل کیفیت.
• قرار دادن تابع تبدیل روی ستون ایندکس‌شده در WHERE و دشوار کردن Index Seek.
• نادیده گرفتن خروجی NULL نسخه‌های TRY و گزارش کردن جمع ناقص به‌عنوان نتیجه کامل.

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

نکات Performance و بهینه‌سازی

هزینه یک تبدیل منفرد معمولاً کم است، ولی ضرب آن در میلیون‌ها ردیف محسوس می‌شود. توابع بومی تبدیل معمولاً سبک‌اند، اما محل اجرای آن‌ها در Plan اهمیت زیادی دارد. Actual Execution Plan، زمان CPU، تعداد خواندن منطقی و تخمین Cardinality را پیش و پس از تغییر مقایسه کنید.

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

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

بهترین روش‌ها

1. نوع مقصد را از مدل کسب‌وکار انتخاب کنید، نه از یک نمونه محدود داده.
2. طول متن و precision و scale عدد را همیشه صریح بنویسید.
3. قالب تاریخ ورودی را ISO یا Style مشخص و مستند نگه دارید.
4. NULL اصلی، شکست تبدیل و نقض دامنه را سه وضعیت جدا در نظر بگیرید.
5. تبدیل را روی پارامتر یا هنگام ورود انجام دهید و ستون ایندکس‌شده را در شرط دست‌نخورده نگه دارید.
6. برای متن فارسی از nvarchar و رشته‌های N استفاده کنید.
7. نتیجه و Plan را با داده واقعی و نسخه هدف SQL Server آزمایش کنید.

کاربردهای واقعی

CAST می‌تواند در ورود فایل فروش، پاک‌سازی داده CRM، تبدیل تاریخ قرارداد، ساخت خروجی API، مهاجرت سامانه قدیمی، کنترل فرم کاربر و آماده‌سازی Data Warehouse استفاده شود. نقطه مشترک همه سناریوها وجود یک قرارداد روشن میان متن خام و نوع استاندارد است.

در پروژه سازمانی بهتر است منطق تبدیل در View یا گزارش‌های متعدد کپی نشود. Procedure ورودی، Pipeline ETL یا لایه سرویس مشترک می‌تواند قرارداد را متمرکز کند. این تمرکز تست، پایش نرخ خطا، تغییر نسخه و ارائه خدمات پشتیبانی پایگاه داده را بسیار ساده‌تر می‌سازد.

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

پرسش متداول 1: CAST در SQL Server دقیقاً چه کاری انجام می‌دهد؟

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

پرسش متداول 2: خروجی و رفتار خطای CAST چگونه است؟

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

پرسش متداول 3: آیا یادگیری CAST برای پروژه‌های تجاری SQL Server ضروری است؟

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

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

قرارداد تبدیل روشن، داده قابل اعتمادتر، گزارش دقیق‌تر و فرآیند ورود مقاوم‌تر می‌سازد. در پروژه‌های سازمانی می‌توان با بازبینی Queryها و مشاوره SQL Server نقاط تبدیل پرریسک را پیش از اختلال شناسایی کرد.

پرسش متداول 5: CAST را در مقایسه با سایر توابع تبدیل چه زمانی انتخاب کنیم؟

وقتی تبدیل استاندارد و بدون Style می‌خواهید انتخاب خوبی است؛ برای داده ناسالم نسخه TRY و برای متن Culture محور خانواده PARSE را بررسی کنید.

پرسش متداول 6: برای پیاده‌سازی CAST در Procedure موجود چه خدمتی لازم است؟

ابتدا نمونه داده، نوع ستون‌ها، تنظیم زبان Session، حجم ردیف و Plan اجرایی بررسی می‌شود. سپس می‌توان نسخه آزمایشی، تست مرزی و راهکار مهاجرت را در قالب مشاوره یا انجام پروژه SQL Server آماده کرد.

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

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

پرسش متداول 8: CAST چه اثری بر Performance دارد؟

خود تبدیل روی تعداد کم ارزان است، اما اجرای آن برای هر ردیف بزرگ یا روی ستون شرط می‌تواند CPU را افزایش و Index Seek را محدود کند. تبدیل را ترجیحاً در مرز ورود یا روی پارامتر انجام دهید.

پرسش متداول 9: بهترین روش استفاده از CAST چیست؟

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

پرسش متداول 10: CAST در کدام نسخه‌های SQL Server قابل استفاده است؟

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

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

سؤال مصاحبه 1: تفاوت تبدیل ضمنی و CAST چیست؟

در تبدیل ضمنی موتور بر اساس اولویت انواع تصمیم می‌گیرد، اما تابع تبدیل قصد و نوع مقصد را صریح می‌کند. تبدیل ضمنی روی سمت نامناسب Join یا Predicate می‌تواند هم خطا و هم افت کارایی ایجاد کند.

سؤال مصاحبه 2: CAST با TRY_CAST چه تفاوتی دارد؟

نسخه TRY برای داده کنترل‌نشده مقاوم‌تر است و شکست معمول را به NULL تبدیل می‌کند؛ نسخه قطعی برای قرارداد معتبر و Fail-fast مناسب است.

سؤال مصاحبه 3: چرا تبدیل ستون در WHERE ممکن است بد باشد؟

چون عبارت روی ستون می‌تواند جست‌وجو را غیر SARGable کند و مانع استفاده مستقیم از کلید مرتب ایندکس شود. معمولاً تبدیل پارامتر یا شرط بازه‌ای Plan بهتری می‌سازد.

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

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

سؤال مصاحبه 5: برای تست تبدیل چه حالت‌هایی لازم است؟

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

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

• نوع مقصد CAST با دامنه واقعی داده هماهنگ است.
• طول متن، precision، scale یا دقت زمانی صریح تعیین شده است.
• رفتار NULL، ورودی خراب و سرریز با تست پوشش داده شده است.
• هیچ تابع غیرضروری روی ستون ایندکس‌شده در Predicate اجرا نمی‌شود.
• خروجی تبدیل ناموفق ثبت، شمارش و برای اصلاح قابل ردیابی است.
• Query روی نسخه هدف SQL Server و با حجم نزدیک تولید آزمایش شده است.

جمع‌بندی

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

برای مقایسه دوباره گزینه‌ها و دسترسی به مقاله‌های مرتبط، به راهنمای جامع CAST، CONVERT، TRY_CAST، TRY_CONVERT، PARSE و TRY_PARSE بازگردید.