May 3, 2007 | SQL Server

Vote Whoring

We've been given this great tool called Connect:*/

We have been granted the ability to provide input on the next version of SQL Server, and influence which problems need the most attention and which features we want added most.  But I don't think we're using it very effectively.

I'd like to point out some of the issues that I think are important, and would like to ask that you take a look at them and weigh in.  And please, browse the other items too, and vote on any that are important to you.

Would you like to see indexed views that support MIN and MAX?  I sure would.*/

Given how many users expect the column to contain date/time info, do you think it's time we remove the synonym TIMESTAMP?*/

Should we cut back on the functionality provided by Open Table, or get rid of it altogether, seeing as it's so broken?*/*/

Can DECLARE @foo VARCHAR and CAST(foo AS VARCHAR) have the same result, instead of one being 1 character and the other being 30?*/

Do you want better, supported and document versions of sp_who2, sp_MSForEachDB, and sp_MSForEachTable?*/*/*/

Can we have the ability to customize the details that show on the tabs for query windows?*/

Do you want the ability to set a default transaction isolation level for users/logins?*/

Are you unhappy with the dynamic SQL and other issues (e.g. those caused by "IF NOT EXISTS" clause) in the scripting options in Management Studio?*/*/

Would you like to see support for IN () and/or BETWEEN in NULLIF?*/

Are you happy with the current output of @@VERSION?  Do we need more similar functions, and/or can we clean this one up a bit?*/

I guess I'm kind of disappointed that I went through enough trouble to submit 113 issues to date (not including those I entered on the previous edition of the system) and that the majority of them have only been voted on by me.  I'm sure others using the system feel the same way.  Please, take advantage of this system, otherwise your voice will not be heard.  And now is the time to do it, not after you have been playing with Katmai for a month (because then it will be too late).

4 comments on this post

    • Alex Kuznetsov - May 3, 2007, 11:24 PM

      Hi Aaron,
      I would respectfully disagree with the request to "see indexed views that support MIN and MAX". My reasoning is as follows:
      Suppose there is an appropriate index. While SUM and COUNT will scan the whole index
      to satisfy your query, MIN and MAX can be satisfied by a simple index seek and as such do not really need to be supported by indexed views.
      More to the point, when you modify your underlying table, you can change your SUM and BIG_COUNT entries in your indexed view using only the data being modified and the corresponding entries in your indexed view.
      Unfortunately this is not the case with MIN and MAX. Suppose you have deleted a row with maximum salary. If you needed to adjust MAX(Salary) in your indexed view, you would have to look up if there are other rows with the same salary, which makes implemetation of indexed views dramatically more complex.
      Once upon a time there were no indexed views yet, and I was manually maintaing my totals in a summary table. At that time I decided to store onyl SUM and COUNT, and not to store MIN and MAX in my summary table, for the reason I described above.
      What do you think?

    • AaronBertrand - May 3, 2007, 11:38 PM

      My reasoning for adding the functionality is to let me decide where to take the performance hit… in writing my own code that does something like it behind the scenes, or having the engine do it in real time.  In cases where you are only adding rows and the aggregate is against an increasing value (e.g. a datetime value representing event date/time) then it really shouldn't be a performance hit as you suggest.
      Of course, the reason for me posting here was to have such comments and debates in the item(s) directly, that way Microsoft can actually observe how people feel and what kind of action they should take (if any).  They're not using this site as a gauge.

    • Alex Kuznetsov - May 4, 2007, 12:35 AM

      I am not suggesting it is a performance hit. I am saying the implementation would be significantly more complex. Also I am saying that the performance advantage over an index seek from a proper index is minimal – as compared to the performance advantage of retrieving SUM from an index view over an index scan which could be huge. Putting on your project managent hat, would you rush to provide a feature with very complex implementation and minimal performance gains?

    • Noral - May 4, 2007, 7:18 PM

      Hi Aaron,
      I have added my own suggestion for SSIS / SSRS, take a look*/*/
      I would love for others to vote for this as well.

Comments are closed.