January 3, 2009 at 2:20 pm
Comments posted to this topic are about the item Just a Second, Guv.
Best wishes,
Phil Factor
January 3, 2009 at 2:39 pm
And, yet, we go on without the ISO/IEC 9075 SQL2008 standard in SQL Server 2008 just as we have done without various other standards for zealots, lunatics, and database politicians of all walks to rant and publicly ponder about.
I was amazed at the recent article on Simple-Talk about temporal data-types. I was even more amazed at the referenced sites and documents. Never have I seen so many people say so much about so little. I'm appalled by the amount of supposed brain-power people spend on such trivial-to-solve-matters and how incensed people become because some bloody RDBMS doesn't have an INTERVAL data-type.
And, no, Phil... none of that is directed at you... it's directed at people like the ones who spend years writing a 598 page book on how to track which lots a cow was in or spending almost a whole article trying to bring back the "important" history surrounding the Unix time base, yet again. I can only pray that no tax-payers dollars were spent as grant or other monies on any of those long winded and basically useless references.
I just want to reach out, grab a handful of their necks, and scream "Speaking of [font="Arial Black"]time[/font], save some and get to the bloody point!" 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
January 3, 2009 at 3:54 pm
Jeff,
What does the standard give us as far as Time-based information goes? As I see it, it is the ability to store time zones along with dates, and have a proper Data Type for Intervals. At the moment we can store intervals, and do arithmetic on them, but because we are storing them as exact numerics, we always have nagging doubts about it because we are mercy of possible changes in the way that DateTimes are stored. We are steering rather close to assuming the way that the data is stored.
I have had to wade through a number of databases that make a pigs breakfast of the whole problem of temporally-based information. Imagine the classic problem. you have a whole lot of products whose prices change the whole time. at any one time, you need to value your inventory. At any point, you have stuff stocked in warehouses across several time-zones. You need to put constraints in to prevent errors where at any point in time, a price is not assigned to a product. Is this really trivial to solve as you suggest?
I have sat through a few presentations on 'Bitemporal' techniques, and started out thinking it was baloney, but after a while I began to appreciate that large international companies really have a problem. I'm not sure I liked many of their solutions because, like you, I have a revulsion for any complexity.
You may think they are time-wasters, but there are complex 'temporal' applications out there, such as transport scheduling, booking systems, and timetabling systems for colleges. Some are more complex than first appears: I spent a lot of time a couple of years ago writing a booking/reservation system for a whole group of Golf courses. I started out like you chuckling, spitting on my hands, and saying it was simple, but the sheer complexity of the arcane rules of business and marketing soon bogged me down. I'm older and ..er.. more cautious now.
And I don't think you're getting at me at all. I'm used to this subject generating more heat than light.
Best wishes,
Phil Factor
January 3, 2009 at 4:36 pm
Nope... I'm right there with you on some of the pig databases, especially considering the "time elements", we've both seen in this world.
And yes, I absolutely agree... there's a lot more heat than light on the subject... slow, pedulous, grinding, not-to-the-point-at-all heat. That 598 or so page PDF I was talking about could have been reduced to a couple of well laid out diagrams, a brief description of the problem, and some actual working code examples with sample data. Instead, someone saw fit to write a novel having little to do with the problems associated with the title of the document.
Heh... I guess I'm bitchin' more about writing style than temporal problems... 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
January 4, 2009 at 5:33 pm
So hopefully you have an external time sync or SQL Server (and Windows) will be a second behind. At least I'm guessing.
And I don't want to see any patch to deal with this.
I'm with Jeff on this. I see the need for it, but I'm glad I don't deal with such precision. It's a PIA.
January 6, 2009 at 9:18 am
The discussion on Joe's article was definitely interesting.
Like most who chimed in, I prefer using DateAdd over Floor/Ceiling, because of consistency. Unlike most who chimed in, I don't tie a lot of emotion into it. It's like getting emotional over mice vs trackballs vs touchpads.
On the subject of storing time zones with times, I do think that's necessary, and I also think an interval data type would be a good thing to have, for much the same reasons Phil gave.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply