Evil Kraig F (12/6/2011)
Rob Schripsema (12/5/2011)
Great question. Not what I would have expected....but then, many aspects of SQLVariants are not what I would expect.
Agreed, it's like opening Pandora's Box. I'm not even sure what led Tom to finding this nugget, nevermind how I'd go about finding the full answer if he hadn't spoon-fed me what was going on in a reasonable amount of time.
Variant can burn from everything I've been seeing on the complexity of its rulesets.
What got me thinking of doing questions on variant order was a comment by someone (I think it was by Hugo in response to an earlier question, but not at all sure) that he had thought of doing a question on variant order but decided the ordering rules were too complex. I had come across variant ordering being misused for a purpose other than indexing some years back, and knew that people using SQL to create EAV systems sometimes got caught up in it. I knew that it was quite well documented in BoL, and the only things I couldn't remember about it was how to discover the locale version (the locale id was OK, but not the version) associated with a collation (couldn't remember that because I had never known it - and still don't, I haven't found it documented anywhere, haven't even looked for it much) and what happened with the newest types (date and datetime2). So I thought that maybe some questions would be amusing SQL trivia, because the rules are not really at all bizarre or complex.
As for using this stuff - well, you can probably guess from my use of the word "misuse" above that I believe that the order on SQL_VARIANT should be used only to support the construction of indexes, especially those associated with primary key and unique constraints. If people want to mess about with EAV models and worry about the order of SQL_VARIANT (beyond knowing that variant columns can be used in indexes and keys) they are, in my view, misguided (on both counts). But the rules are still fun SQL trivia.