Coming In August

  • Comments posted to this topic are about the item Coming In August

  • One other feature with SQL 2008, which is seldom mentioned is the new multi-server query in SSMS 2008. This is a really useful feature where you can run a query across multiple servers in a server registration group and produce a single result set with the SQL instance automatically appended as the first column. Works against 2000, 2005, and 2008 servers. I've been using multi-server query since CTP 5 to quickly produce stats across the 150 SQL Servers I manage.

  • Multi-server query sounds cool, could be very nice for consolidating job execution and DBCC info. I'm VERY thankful for separate date and time data types, I like the combined type, but there are times when it will drive you nuts. The spatial data type is very good for people running GIS apps like ArcInfo and the rest of the ESRI suite, which is basically every state, county, and local government, plus forestry, geology industries, law enforcement, etc. It exists in Oracle and DB/2, it was implemented in SQL Server as a varbinary. I think adding the spatial data type will add a lot of third-party value to SQL Server once programmers start working with it.

    -----
    [font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]

  • I like all the changes that I have seen so far and everything indicates that it is an improvement over SQL Server 2005.

    Unfortunately, it looks like there is nothing in it which is compelling enough, at least for my current situation as a DBA, to justify the corporate money and man hours which would need to be spent upgrading and testing.

    And no matter how little they say they have changed, I would suggest doing thorough testing when moving to a new version. In fact, I would say it is generally a good idea to do some testing before rolling out service packs much less a new version.

    ---
    Timothy A Wiseman
    SQL Blog: http://timothyawiseman.wordpress.com/

  • Not every organization will be able to reap benefits by moving to 2008 however, if you have the chance you should go. The one thing I will state emphatically is that if you are thinking of going to 2005 from 2000, don't bother. Make the leap.

    Aside from the things Steve mentioned, SSMS has had some improvements which are pretty cool as well like Intellisense and the display of missing indexes when looking at execution plans (only able to be viewed when you looked at the often confusing XML plans in 2005). I will probably post about some of these features in my blog in the next couple of days when I get time to breathe.

    David

    @SQLTentmaker

    β€œHe is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot

  • Date and Time!! - They're finally separate so you can query as salesdate > '2008/07/09' instead of salesdate > '2008/07/09 00:00:00'.

    You can do that in all versions of SQL Server since 6.5... nothing new there.

    I, too, can't wait until the split of Date and Time... leaves much opportunity to easily get to 15,000 posts in a hurry explaining to people how to fix what they have unwittingly done by using the split. πŸ˜‰

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • cmille19 (7/10/2008)


    One other feature with SQL 2008, which is seldom mentioned is the new multi-server query in SSMS 2008.

    Works against 2000, 2005, and 2008 servers.

    It works to SQL 7 boxes as well.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Jeff Moden (7/10/2008)


    I, too, can't wait until the split of Date and Time... leaves much opportunity to easily get to 15,000 posts in a hurry explaining to people how to fix what they have unwittingly done by using the split. πŸ˜‰

    I can see times when only a date is needed, or only a time, however I foresee lots of people having a data and a time stored in different columns in 1 table when they should be stored in a datetime.

    Is gonna be fun doing a between when the date and the time are separate. :hehe:

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • GilaMonster (7/11/2008)


    I can see times when only a date is needed, or only a time...

    It's probably because I've not had enough coffee this morning, yet... :hehe: can you tell me when you see a serious advantage to having only a date or a time column why wouldn't storing just Date or just Time isn't some form of "lost data"? Even storing duration as just a TIME is a problem because you'd never be able to store values over 24 hours.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • A time table - Physics 101, Lecture room 2B, 9am every monday.

    Movie schedules. Movie X shows every day this week at 17:00, 20:30 and 23:00

    A store list with their opening and closing times

    An example I've actually used - storing the start time and end time of daily jobs

    I can certanly do that with a datetime (and I have done it), but then I have to set some form of meaningless date.

    Is it the norm? No. Are there cases where it's useful? Absolutely.

    I would never store duration as a time. That's asking for nasty maths. Store is as a number of hours/minutes/seconds, depending on the granularity required.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Jeff Moden (7/11/2008)... Even storing duration as just a TIME is a problem because you'd never be able to store values over 24 hours. ...

    That's my one problem with the time data type, what if you're storing durations > 24 hours? I guess we'll end up multiplying it up by minutes or seconds and storing it in an integer with a UDF to pretty format it for us.

    DateTime is definitely not going away! But for things like invoices, where you don't care what time they arrived, it'll be good.

    -----
    [font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]

  • GilaMonster (7/11/2008)


    A time table - Physics 101, Lecture room 2B, 9am every monday.

    Movie schedules. Movie X shows every day this week at 17:00, 20:30 and 23:00

    A store list with their opening and closing times

    An example I've actually used - storing the start time and end time of daily jobs

    I can certanly do that with a datetime (and I have done it), but then I have to set some form of meaningless date.

    Is it the norm? No. Are there cases where it's useful? Absolutely.

    I would never store duration as a time. That's asking for nasty maths. Store is as a number of hours/minutes/seconds, depending on the granularity required.

    Heh... I had the feeling you'd say that... I think all of that is more for formatting for folks that can't get over the 19000101 meaningless date because storing a time with the meaningless 19000101 date works just as well. Yeah... it is 4 bytes longer than the Time datatype, though.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I'd think the biggest issue with datetime is the "doh!" that you say everytime a report looks for sales on a date, forgetting there's a time component.

    How many of you have looked for salesdate = getdate() or salesdate = '2008/07/11" and wonder why it looks like the company's going under? I've done that in the last 5 years, even after writing reports all week that say > date1 and < date2, I slip one in that doesn't work.

    Doh!

  • That's all well and good... I guess people who are unaware could use the help of the Date and Time datatypes. What I'm waiting for is the people who do an import of data and then trim the "CreateDate" to just a Date... and then their boss says, "I need an aggregate report by hour." There's a big "DOH!" waiting right there and that's what I meant by "lost data".

    The same people who forget about the time element that you spoke of are the same one's who are going to get their pants pulled down by such an oversight. It's so easy to make a calculated column to split Date and Time... I wish Microsoft had focused their efforts on making aggregates work more correctly with OVER to allow for such things as set based running totals and the like.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • It's going to be one or the other all the time.

    They're planing SQL 11, or about to, so I'd encourage Jeff to hit the MVP groups and post suggestions for the team there. Itzak will probably chime in as well.

Viewing 15 posts - 1 through 15 (of 28 total)

You must be logged in to reply to this topic. Login to reply