June 4, 2015 at 10:52 pm
Comments posted to this topic are about the item Filtered Indexes 2
June 4, 2015 at 10:53 pm
Good question. I had to think for a moment about the implicit conversion that could possibly happen depending on how the columns were defined (gender and username). But that didn't really come in to play since the conversions would actually be on the right.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
June 5, 2015 at 12:43 am
Easy one, thanks.
Have a nice weekend all!
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
June 5, 2015 at 12:45 am
Easy One. Solved similar one recently 🙂
June 5, 2015 at 4:57 am
This was removed by the editor as SPAM
June 5, 2015 at 5:05 am
I had to think about this one as well. Good way to get the brain moving in the morning. Thanks and have a great weekend.
June 5, 2015 at 8:20 am
Of course we have to assume that neither username nor gender are "a computed column, a UDT column, a spatial data type column, or a hierarchyID data type column" as stated in the reference.
June 5, 2015 at 10:02 am
Thanks for the question! I don't recall where I learned this (prob somewhere on SSC), but wherever I did, it helped me get the right answer. 🙂
-webrunner
-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
June 5, 2015 at 10:43 am
Filtered indexes are defined on one table and only support simple comparison operators. If you need a filter expression that references multiple tables or has complex logic, you should create a view. This is one the limitations in sql 2014 out of many. May be sql 2016 can overcome these restrictions.
Thanks.
June 5, 2015 at 8:37 pm
SQL-DBA-01 (6/5/2015)
Filtered indexes are defined on one table and only support simple comparison operators. If you need a filter expression that references multiple tables or has complex logic, you should create a view. This is one the limitations in sql 2014 out of many. May be sql 2016 can overcome these restrictions.
The multiple tables part of that is true of all indexes, not just filtered ones. I hope that part of it won't be fixed in SQL 2016, since it would be positively bizarre for an index on a table to refer to columns in that table. As for complex logic, it would be reasonable to allow the same logic in a filter as is allowed in a check constraint (ie any logical expression that doesn't reference another table or another row in the same table or anything whose type is an alias type), so it would not be bizarre to fix just that part of the problem. Allowing anything more complex than allowed for a check constraint would be pretty bizarre, I think.
Tom
June 8, 2015 at 1:51 am
I had to look very carefully.
At first sight all options were right.
But 3 had to be right ...
Thanks
June 8, 2015 at 2:21 am
Another good practice on Filtered Index, thanx.
Thanks & Best Regards,
Hany Helmy
SQL Server Database Consultant
June 8, 2015 at 2:57 am
timwell (6/5/2015)
Of course we have to assume that neither username nor gender are "a computed column, a UDT column, a spatial data type column, or a hierarchyID data type column" as stated in the reference.
+1
June 8, 2015 at 6:58 am
Hany Helmy (6/8/2015)
Another good practice on Filtered Index, thanx.
Agreed
June 8, 2015 at 8:27 am
Nice question, thanks.
____________________________________________________
Deja View - The strange feeling that somewhere, sometime you've optimised this query before
How to get the best help on a forum
http://www.sqlservercentral.com/articles/Best+Practices/61537Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply