مقدمه

تابع LOG یکی از ابزارهای ریاضی SQL Server برای لگاریتم طبیعی یا با مبنا است. در پروژه واقعی، دانستن نام تابع کافی نیست؛ باید نوع داده ورودی، دامنه معتبر، دقت خروجی، رفتار NULL و اثر عبارت بر Execution Plan را نیز بشناسیم. این مقاله از یک Query ساده شروع می‌کند و تا الگوهای گزارش سازمانی و بهینه‌سازی پیش می‌رود.

محتوا برای اجرا در Microsoft SQL Server نوشته شده است. همه مثال‌ها مستقل‌اند و می‌توان آن‌ها را در یک Query Window آزمایش کرد. برای دیدن جایگاه این تابع در کنار دیگر ابزارهای عددی، راهنمای جامع توابع ریاضی SQL Server را مطالعه کنید.

تعریف و کاربرد تابع LOG

LOG مقدار ورودی را برای لگاریتم طبیعی یا با مبنا ارزیابی می‌کند. دامنه معتبر آن چنین است: عبارت باید مثبت باشد؛ مبنا مثبت و نابرابر با یک. نتیجه تابع در محاسبات تحلیلی، تبدیل داده، ساخت KPI، کنترل کیفیت و آماده‌سازی خروجی گزارش قابل استفاده است؛ بااین‌حال انتخاب نوع داده باید متناسب با دقت مورد انتظار انجام شود.

LOG در حالت تک‌پارامتری لگاریتم طبیعی است؛ آن را با LOG10 اشتباه نگیرید. این نکته در داده‌های انبوه اهمیت بیشتری دارد، زیرا یک مقدار خارج از دامنه یا تبدیل ضمنی نامناسب می‌تواند کل Query را متوقف کند یا عددی ظاهراً معتبر ولی از نظر کسب‌وکار اشتباه بسازد.

قاعده حرفه‌ای: پیش از استفاده از LOG روی داده Production، دامنه ورودی، رفتار NULL، نوع خروجی و مقادیر مرزی را با داده نماینده آزمایش کنید.

نحو یا Syntax

SELECT LOG ( float_expression [, base ] );

پارامترها و نوع خروجی

مثال‌های عملی تابع LOG

مثال شماره 1: فراخوانی پایه با مقدار ثابت

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

SELECT LOG(EXP(1.0)) AS Result;

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

مثال شماره 2: اجرا روی مجموعه داده نمونه

این سناریو سه مقدار متفاوت را با سازنده VALUES ایجاد می‌کند و نتیجه LOG را برای هر ردیف جداگانه نشان می‌دهد. چنین الگویی برای آزمایش سریع مرزها پیش از استفاده روی جدول اصلی بسیار مفید است.

WITH SampleValues(v) AS
(
    SELECT *
    FROM (VALUES (1.0),(2.718281828459045),(10.0)) AS S(v)
)
SELECT
    v AS InputValue,
    LOG(v) AS CalculatedValue
FROM SampleValues;

نکته کاربردی: پیش از استقرار، نمونه‌ها را با کمینه، بیشینه، صفر و مقادیر نزدیک مرز دامنه کامل کنید.

مثال شماره 3: استفاده در فهرست SELECT

در گزارش‌ها معمولاً هم مقدار خام و هم مقدار محاسبه‌شده لازم است. این مثال نام کالا، مقدار اندازه‌گیری‌شده و خروجی LOG را در یک Projection برمی‌گرداند تا مقایسه و کنترل نتیجه آسان باشد.

WITH Measurements(ItemName, v) AS
(
    SELECT N'نمونه الف', CONVERT(float, 0.5) UNION ALL
    SELECT N'نمونه ب', CONVERT(float, 1.0) UNION ALL
    SELECT N'نمونه ج', CONVERT(float, -0.5)
)
SELECT
    ItemName,
    v AS RawValue,
    CASE WHEN v > 0 THEN LOG(v) END AS CalculatedValue
FROM Measurements;

نکته کاربردی: اگر داده از منبع بیرونی می‌آید، TRY_CONVERT و کنترل دامنه را در لایه پاک‌سازی داده انجام دهید.

مثال شماره 4: فیلتر کردن داده پیش از محاسبه

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

WITH Numbers(v) AS
(
    SELECT * FROM (VALUES (-2.0),(-0.5),(0.0),(0.5),(2.0)) AS N(v)
)
SELECT v, CASE WHEN v > 0 THEN LOG(v) END AS CalculatedValue
FROM Numbers
WHERE v >= -1.0 AND v <= 1.0;

نکته کاربردی: در جدول واقعی، تا حد امکان تابع را دور ستونِ سمت چپ شرط WHERE قرار ندهید؛ بازه معادل را روی خود ستون بنویسید.

مثال شماره 5: ترکیب با یک تابع دیگر

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

SELECT LOG(8.0, 2.0) AS CombinedResult;

نکته کاربردی: ترتیب تبدیل نوع، محاسبه و گردکردن را مستند کنید؛ جابه‌جایی این مراحل می‌تواند نتیجه نهایی را تغییر دهد.

مثال شماره 6: رفتار تابع در برابر NULL

بیشتر توابع عددی SQL Server با دریافت NULL، مقدار NULL بازمی‌گردانند. این رفتار برای حفظ مفهوم «نامعلوم» مفید است؛ ولی در گزارش نهایی می‌توان با CASE یا COALESCE سیاست جایگزینی مشخصی اعمال کرد.

DECLARE @Input float = NULL;

SELECT
    CASE WHEN @Input > 0 THEN LOG(@Input) END AS NullResult,
    CASE WHEN COALESCE(@Input, 0.0) > 0 THEN LOG(COALESCE(@Input, 0.0)) END AS ResultAfterDefault;

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

مثال شماره 7: بررسی حالت مرزی

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

SELECT LOG(1.0) AS EdgeResult;

نکته کاربردی: LOG در حالت تک‌پارامتری لگاریتم طبیعی است؛ آن را با LOG10 اشتباه نگیرید.

مثال شماره 8: سناریوی واقعی گزارش سازمانی

در این سناریو داده‌های یک شاخص عملیاتی در CTE ساخته می‌شوند و LOG برای تولید ستون تحلیلی گزارش به کار می‌رود. همین ساختار را می‌توان روی فروش، بودجه، سنجش مهندسی یا کنترل کیفیت توسعه داد.

WITH BusinessData(RowId, ActualAmount, BudgetAmount, Quantity, AvailableMinutes, CurrentBalance, PreviousBalance, TargetAmount, UnitPrice, X1, Y1, X2, Y2) AS
(
    SELECT 1, 120.0, 100.0, 48.0, 180.0, 125.0, 110.0, 115.0, 250.0, 0.0, 0.0, 3.0, 4.0
)
SELECT RowId, LOG(200.0 / 100.0) AS BusinessMetric
FROM BusinessData;

نکته کاربردی: نام ستون محاسبه‌شده و واحد آن را شفاف بنویسید تا مصرف‌کنندگان گزارش، درجه و رادیان یا مقدار خام و درصد را اشتباه نگیرند.

مثال شماره 9: جلوگیری از خطای دامنه یا تبدیل

به‌جای اعتماد به داده ورودی، نسخه ایمن ابتدا مقدار متنی را با TRY_CONVERT به عدد تبدیل می‌کند و سپس شرط دامنه تابع را اعمال می‌نماید. داده نامعتبر به NULL تبدیل می‌شود و کل Batch را متوقف نمی‌کند.

DECLARE @RawValue nvarchar(30) = N'0.75';
DECLARE @v float = TRY_CONVERT(float, @RawValue);

SELECT
    @RawValue AS RawValue,
    CASE WHEN @v > 0 THEN LOG(@v) END AS SafeResult;

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

مثال شماره 10: الگوی مناسب برای کارایی و ایندکس

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

WITH IndexedLikeData(Id, v) AS
(
    SELECT 1, CONVERT(float, -10.0) UNION ALL
    SELECT 2, CONVERT(float, 0.5) UNION ALL
    SELECT 3, CONVERT(float, 10.0)
)
SELECT Id, v, CASE WHEN v > 0 THEN LOG(v) END AS CalculatedValue
FROM IndexedLikeData
WHERE v >= 0.0
ORDER BY Id;

نکته کاربردی: برای عبارت پرتکرار و قطعی، ستون محاسباتی Persisted و ایندکس آن را فقط پس از سنجش هزینه نگهداری بررسی کنید.

خطاهای رایج

• ارسال داده خارج از دامنه معتبر تابع؛ دامنه LOG برابر است با: عبارت باید مثبت باشد؛ مبنا مثبت و نابرابر با یک.
• اعتماد به تبدیل ضمنی میان int، decimal و float و از دست دادن دقت یا ظرفیت.
• جایگزین کردن خودکار NULL با صفر بدون تأیید منطق کسب‌وکار.
• گرد کردن زودهنگام نتیجه و انباشته شدن خطا در محاسبات چندمرحله‌ای.
• قرار دادن LOG دور ستون در WHERE و از بین بردن امکان Index Seek.

برای عیب‌یابی، ورودی میانی را در یک ستون جدا نمایش دهید، نوع آن را با SQL_VARIANT_PROPERTY بررسی کنید و Query را روی کمینه، بیشینه، صفر، NULL و مرز دامنه اجرا نمایید. LOG در حالت تک‌پارامتری لگاریتم طبیعی است؛ آن را با LOG10 اشتباه نگیرید.

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

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

اگر یک محاسبه ثابت است، آن را یک بار در متغیر یا CROSS APPLY محاسبه کنید. برای عبارت پرتکرار، ستون محاسباتی Persisted تنها زمانی مناسب است که تابع و عبارت قطعی باشند و هزینه فضای ذخیره‌سازی و Update با سود جست‌وجو توجیه شود.

Execution Plan واقعی، STATISTICS IO و STATISTICS TIME معیار تصمیم هستند. بهینه‌سازی را بر اساس حدس یا تعداد خطوط Query انجام ندهید؛ نسخه پایه و نسخه پیشنهادی را با پارامترها و حجم مشابه Production مقایسه کنید.

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

1. نوع ورودی و خروجی را پیش از طراحی ستون یا API مشخص کنید.
2. قاعده دامنه LOG را در مرحله اعتبارسنجی داده اعمال کنید.
3. برای محاسبات مالی از decimal مناسب و برای محاسبات علمی از float با آگاهی از تقریب استفاده کنید.
4. نتیجه NULL، خطا و مقدار خارج از محدوده را به‌صورت صریح مدیریت کنید.
5. واحد خروجی مانند درجه، رادیان، درصد یا مقدار خام را در نام ستون و مستندات ثبت کنید.
6. مثال‌های مرزی را به تست رگرسیون اضافه کنید و پس از ارتقای نسخه دوباره اجرا نمایید.

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

تابع LOG در SQL Server دقیقاً چه کاری انجام می‌دهد؟

LOG برای لگاریتم طبیعی یا با مبنا به کار می‌رود و ورودی را مطابق قواعد عددی SQL Server پردازش می‌کند. شناخت نوع ورودی، دامنه معتبر و نوع خروجی باعث می‌شود نتیجه در گزارش یا محاسبه سازمانی قابل اعتماد باشد.

چگونه Syntax تابع LOG را یاد بگیریم؟

بهترین روش این است که ابتدا نحو LOG ( float_expression [, base ] ) را با مقدار ثابت اجرا کنید، سپس همان عبارت را روی چند ردیف نمونه و در نهایت روی نسخه آزمایشی جدول واقعی بسنجید. مثال‌های این مقاله همین مسیر را مرحله‌به‌مرحله پوشش می‌دهند.

آیا آموزش LOG برای پروژه‌های تجاری SQL Server مفید است؟

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

هزینه پیاده‌سازی محاسبات مبتنی بر LOG چگونه برآورد می‌شود؟

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

تفاوت LOG با نوشتن محاسبه دستی چیست؟

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

برای پیاده‌سازی یا بهینه‌سازی Queryهای LOG از چه خدمتی می‌توان کمک گرفت؟

در پایگاه‌داده‌های حساس می‌توان از بازبینی Query، مشاوره مدل داده و تست Execution Plan استفاده کرد. هدف خدمات حرفه‌ای باید تحویل Query قابل سنجش، مستند و سازگار با داده واقعی باشد، نه صرفاً افزودن تابع به SELECT.

رایج‌ترین خطای LOG چیست؟

LOG در حالت تک‌پارامتری لگاریتم طبیعی است؛ آن را با LOG10 اشتباه نگیرید. خطای دیگر، اتکا به تبدیل ضمنی و نادیده گرفتن NULL است. استفاده از TRY_CONVERT، CASE و تست مقادیر مرزی ریسک توقف Batch یا تولید عدد گمراه‌کننده را کم می‌کند.

آیا استفاده از LOG روی ستون ایندکس‌شده Performance را کاهش می‌دهد؟

اگر تابع مستقیماً در شرط WHERE دور ستون قرار گیرد، ممکن است شرط SARGable نباشد و Seek به Scan تبدیل شود. بهتر است بازه معادل روی ستون خام نوشته شود و محاسبه پس از فیلتر انجام گیرد.

Best Practice اصلی برای LOG چیست؟

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

تابع LOG با کدام نسخه‌های SQL Server سازگار است؟

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

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

نوع خروجی LOG چگونه تعیین می‌شود؟

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

چگونه ورودی نامعتبر LOG را مدیریت می‌کنید؟

با TRY_CONVERT، CASE، محدودیت دامنه و ثبت ردیف خطادار. پاسخ حرفه‌ای باید میان اصلاح داده و پنهان کردن خطا تفاوت بگذارد.

چرا استفاده از LOG در WHERE ممکن است مسئله‌ساز شود؟

زیرا تابع‌گذاری روی ستون ایندکس‌شده می‌تواند شرط را غیر SARGable کند. بازنویسی بازه روی ستون خام معمولاً امکان Seek بهتری می‌دهد.

چه زمانی ستون محاسباتی Persisted مناسب است؟

زمانی که عبارت قطعی و پرتکرار است، جست‌وجو یا مرتب‌سازی از ایندکس سود می‌برد و هزینه Update و فضا با اندازه‌گیری پذیرفتنی است.

چه تست‌هایی برای LOG می‌نویسید؟

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

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

• Syntax با نوع داده واقعی آزمایش شد.
• دامنه و NULL کنترل شدند.
• نوع و واحد خروجی مستند شد.
• ده مثال از ساده تا سازمانی اجرا شدند.
• Predicateها از نظر SARGability بازبینی شدند.
• Execution Plan و IO روی حجم نماینده سنجیده شد.

جمع‌بندی

تابع LOG راه استاندارد SQL Server برای لگاریتم طبیعی یا با مبنا است. استفاده مطمئن از آن به کنترل دامنه، انتخاب نوع، مدیریت NULL و سنجش کارایی وابسته است. مثال‌های این راهنما نشان دادند که چگونه از مقدار ثابت به گزارش سازمانی و Query قابل بهینه‌سازی برسیم.

برای مقایسه LOG با توابع هم‌خانواده و انتخاب ابزار مناسب، به مقاله جامع آموزش توابع ریاضی در SQL Server بازگردید.