Variant order 1

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » Article Discussions » Article Discussions by Author » Discuss content posted by Tom Thomson » Variant order 1

59 posts, Page 6 of 6

«««2 3 4 5 6

Variant order 1

Rate Topic

Display Mode

Topic Options

Author

Message

Tom_Sacramento

Posted Wednesday, November 30, 2011 12:09 PM

SSCommitted

Group: General Forum Members
Last Login: 2 days ago @ 6:42 AM
Points: 1,768, Visits: 465

In the interest of being exact, the answers given transpose the 3rd field so there was not exactly correct answer given...

Here is the result:

v1 > v2 v1 > v3 v3 = v2 v4 > v1

Tom in Sacramento

For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/

Post #1214174

David Data

Posted Thursday, December 01, 2011 4:19 AM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, May 07, 2013 3:28 AM
Points: 115, Visits: 719

I see that even if you set

@v1 sql_variant = cast ('15.00' as float(53)),
@v2 sql_variant = cast ('16.00' as decimal(18,4)),

which makes

v1 v2
15 16.0000

SQL Server still says v1 > v2.

This behaviour is very counter-intuitive - to say nothing of being arithmetically incorrect!

It would be better if it produced the result one would expect - or if it won't, if it refused to do such comparisons. I can imagine many data errors being caused by people not noticing this behaviour and believing the wrong results they get.

Post #1214488

Britt Cluff

Posted Thursday, December 01, 2011 6:09 AM

SSCommitted

Group: General Forum Members
Last Login: Wednesday, October 24, 2012 8:17 PM
Points: 1,558, Visits: 247

Good question, but a lot of reading. Thanks for submitting.

http://brittcluff.blogspot.com/

Post #1214567

Carla Wilson-484785

Posted Thursday, December 01, 2011 7:50 AM

Ten Centuries

Group: General Forum Members
Last Login: Yesterday @ 1:39 PM
Points: 1,355, Visits: 1,740

Toreador (11/30/2011)

KWymore (11/30/2011)

I am curious how many out there are utilizing sql_variant and under which circumstances?

I've used it for generic audit tables, where we store something like table name, column name, old value, new value - the old/new values are sql_variant as they could be any data type.
Of course you'd never do any comparisons between different data types in these circumstances.

Toreador, thanks! I, too, was wondering where one would use sql_variant - now it seems obvious.

That said, I appreciate David Data's comment:

David Data (12/1/2011)

I see that even if you set

@v1 sql_variant = cast ('15.00' as float(53)),
@v2 sql_variant = cast ('16.00' as decimal(18,4)),

which makes

v1 v2
15 16.0000

I really don't understand why someone would want to do a comparison that is based on the data type. I can only guess that they chose to set it up this way to avoid errors that might occur in implicit conversions. The lesson I learn from this is to not do comparisons on sql_variant.

Post #1214641

Hugo Kornelis

Posted Thursday, December 01, 2011 8:15 AM

SSCertifiable

Group: General Forum Members
Last Login: Today @ 3:49 PM
Points: 5,244, Visits: 7,063

Carla Wilson-484785 (12/1/2011)

I really don't understand why someone would want to do a comparison that is based on the data type.

Well, I guess the issue is that the SQL Server development team had to choose between allowing > and < comparisons for sql_variant (and makinig it work in all cases), or not allowing it at all.

They chose the former, and then had to come up with a way to compare the numeric value 15, the string value N'fünfzehn', the date December 1st, 2011, and the bit value 1. Which one is more than the others? And why? They had to make a choice - but whatever their choice was, it was bound to be perceived as wrong for some cases.
That being said, I do share your amazement at the choice to put exact and inexact numerics in two different groups. It appears this choice was born out of technical rather than functional considerations.

The lesson I learn from this is to not do comparisons on sql_variant.

Amen to that!

Hugo Kornelis, SQL Server MVP
Visit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis

Post #1214672

L' Eomot Inversé

Posted Thursday, December 01, 2011 12:48 PM

SSCertifiable

Group: General Forum Members
Last Login: Today @ 11:54 AM
Points: 7,112, Visits: 7,188

Hugo Kornelis (12/1/2011)

Carla Wilson-484785 (12/1/2011)

I really don't understand why someone would want to do a comparison that is based on the data type.

Well, I guess the issue is that the SQL Server development team had to choose between allowing > and < comparisons for sql_variant (and makinig it work in all cases), or not allowing it at all.

Given that they wanted people to be able to construct indexes on sql_variant columns, they didn't have a choice - they had to provide a total order on SQL_VARIANTs. Not allowing it at all was not an option.

They chose the former, and then had to come up with a way to compare the numeric value 15, the string value N'fünfzehn', the date December 1st, 2011, and the bit value 1. Which one is more than the others? And why? They had to make a choice - but whatever their choice was, it was bound to be perceived as wrong for some cases.
That being said, I do share your amazement at the choice to put exact and inexact numerics in two different groups. It appears this choice was born out of technical rather than functional considerations.

I can't really think of any purely "technical" considerations that would suggest making them two separate type families; perhaps an awareness that conversion from exact to inexact numerics (which is the conversion that would have to be done to allow comparison if they were in the same group) can cause bizarre rounding effects (as can the conversion in the opposite direction, of course) could be considered a technical consideration but I would consider avoiding such effects as a fundamental requirement of indexing (and in particular of having UNIQUE constraints supported by indexes) so I see it as rather an essential requirement of the SQL data model rather than something merely "technical".

The lesson I learn from this is to not do comparisons on sql_variant.

Amen to that!

[/quote]
Yes, Amen to that from me too - as far as I am concerned, the only real uses for SQL_VARIANT ordering are (i) to support indexes and unique constraints and (ii) to provide material for technical trivia questions like this one.

Tom
Is minic a gheibheann béal oscailte dorn dúnta.
Is minig a cheapas beul fosgailte dòrn dùinte.

Post #1214925

Carla Wilson-484785

Posted Friday, December 02, 2011 1:40 PM

Ten Centuries

Group: General Forum Members
Last Login: Yesterday @ 1:39 PM
Points: 1,355, Visits: 1,740

L' Eomot Inversé (12/1/2011)

Hugo Kornelis (12/1/2011)

Carla Wilson-484785 (12/1/2011)

I really don't understand why someone would want to do a comparison that is based on the data type.

Well, I guess the issue is that the SQL Server development team had to choose between allowing > and < comparisons for sql_variant (and makinig it work in all cases), or not allowing it at all.

Thanks, that makes sense.

L' Eomot Inversé (12/1/2011)

Hugo Kornelis (12/1/2011)

The lesson I learn from this is to not do comparisons on sql_variant.

Amen to that!

Yes, Amen to that from me too - as far as I am concerned, the only real uses for SQL_VARIANT ordering are (i) to support indexes and unique constraints and (ii) to provide material for technical trivia questions like this one.

Fair enough! (thanks for the explanations!) Tongue