The various schemes for encoding numbers all have advantages and disadvantages. SQL Server uses a decimal type that has fixed precision and scale. All expressions have a well-defined type, and for SQL Server that means fixed precision and scale if that type is decimal. For example, the computed column in the following table has a type of DECIMAL(19,8):

CREATE TABLE dbo.Example

(

col1 DECIMAL(9,4) NULL,

col2 DECIMAL(9,4) NULL,

col3 AS col1 * col2

)

GO

EXECUTE sys.sp_columns

@table_owner = N'dbo',

@table_name = N'Example',

@column_name = N'col3'

There are many quirks to SQL Server, including the way it handles rounding, truncation, and conversions. In many cases these quirks are preserved to avoid breaking existing applications. That's a purely practical matter, and doesn't imply that everyone is happy about the state of affairs, or wouldn't approach things differently if done again. On that note, the proper place to suggest improvements or alternatives is Connect. By and large, the people that make decisions about future product directions do not carefully read QotD comments.

The point of this QotD is very much to emphasise that using excessive precision or scale can have unintended consequences. Very few real-world uses would require anything like the DECIMAL(38,20) types specified in the question. Using appropriate types (which in SQL Server can include both precision and scale) is important.

As far as I recall, the issue with multiplying or dividing by one was a bug in type inference, which has since been fixed.