I know that the NUMERIC and DECIMAL data types in SQL Server work the same: the syntax for creating them is the same, the ranges of values you can store in them is the same, etc.
However, the MSDN documentation describes the relationship between the two as this:
numeric is functionally equivalent to decimal.
Normally, when I see the the qualifier "functionally equivalent", it means that the two things aren't exactly the same , but that they are two different types that are indistinguishable from the outside.
Is this implication true? Are there differences between NUMERIC and DECIMAL that just happen to behave the same to an outside observer? Or are they actually equivalent, e.g. is NUMERIC just a legacy synonym for DECIMAL?
Best Answer
They are actually equivalent, but they are independent types, and not technically synonyms, like
ROWVERSION
andTIMESTAMP
- though they may have been referred to as synonyms in the documentation at one time. That is a slightly different meaning of synonym (e.g. they are indistinguishable except in name, not one is an alias for the other). Ironic, right?What I interpret from the wording in MSDN is actually:
Other than the
type_id
values, everything here is identical:I have absolutely no knowledge of any behavioral differences between the two, and going back to SQL Server 6.5, have always treated them as 100% interchangeable.
Only if you do so explicitly. You can prove this easily by creating a table and then inspecting the query plan for queries that perform explicit or - you might expect - implicit conversions. Here's a simple table:
Now run these queries and capture the plan:
As shown in SQL Sentry Plan Explorer*, the plan is not really interesting:
But the Expressions tab sure is:
As I commented above, we have explicit conversions where we asked for them, but no explicit conversions where we might have expected them. Seems the optimizer is treating them as interchangeable, too.
Go ahead and try this test, too (data and indexes).
Now run this query:
Plan has no conversions (in fact the Expressions tab is empty):
Even these don't lead to any unexpected conversions. Of course you see it on the RHS in the predicate, but in no case did any conversion have to occur against the column data to facilitate the seek (much less force a scan).
Personally, I prefer to use the term
DECIMAL
just because it's much more accurate and descriptive.BIT
is "numeric" too.