Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««23456

Variant order 1 Expand / Collapse
Author
Message
Posted Wednesday, November 30, 2011 12:09 PM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Friday, April 11, 2014 10:46 AM
Points: 2,108, Visits: 560

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
Posted Thursday, December 01, 2011 4:19 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, April 17, 2014 9:26 AM
Points: 115, Visits: 739
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
Posted Thursday, December 01, 2011 6:09 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Wednesday, October 24, 2012 8:17 PM
Points: 1,588, Visits: 247
Good question, but a lot of reading. Thanks for submitting.

http://brittcluff.blogspot.com/
Post #1214567
Posted Thursday, December 01, 2011 7:50 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Tuesday, April 15, 2014 3:30 PM
Points: 1,525, Visits: 1,833
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

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.


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
Posted Thursday, December 01, 2011 8:15 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 10:24 AM
Points: 5,794, Visits: 8,009
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
Posted Thursday, December 01, 2011 12:48 PM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Yesterday @ 8:37 AM
Points: 8,287, Visits: 8,738
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
Post #1214925
Posted Friday, December 02, 2011 1:40 PM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Tuesday, April 15, 2014 3:30 PM
Points: 1,525, Visits: 1,833
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.

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.

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!)
Post #1215684
Posted Monday, December 05, 2011 1:15 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 12:22 AM
Points: 12,206, Visits: 9,170
Great question, thanks!



How to post forum questions.
Need an answer? No, you need a question.
What’s the deal with Excel & SSIS?

Member of LinkedIn. My blog at LessThanDot.

MCSA SQL Server 2012 - MCSE Business Intelligence
Post #1216092
Posted Thursday, August 02, 2012 8:36 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, November 05, 2013 6:08 AM
Points: 1,076, Visits: 591
nice one

What you don't know won't hurt you but what you know will make you plan to know better
Post #1339222
« Prev Topic | Next Topic »

Add to briefcase «««23456

Permissions Expand / Collapse