November 1, 2017 at 1:31 pm
the DST thing disappear entirely. Nothing but a PITA, and that's being generous.
Gives us more daylight in the evening during summer instead of in the morning when most people are still asleep.
November 1, 2017 at 1:34 pm
RonKyle - Wednesday, November 1, 2017 1:24 PMI still don't see the use case. NULL is NULL. An "unknown" bucket doesn't have a lot of meaning beyond knowing how much of your data has that characteristic, but you don't need a dimension table join for that purpose, and as you can't join on a NULL value anyway, I fail to see the point. Care to provide the logic behind the idea?
All dimension should have an unknown bucket, or use the built in unknown member, or have some way of identifying records that are outside of the expected parameters. While some of my unknown buckets never get used, the one associated with my work order completed date gets used a lot because if the completed date is before the created date or missing (but the status is completed) or more than one day in the future, it gets assigned to the unknown bucket. Time works the same way. As a practical matter, the time is never incorrectly formatted due to data types. But if it's missing and it shouldn't be or it's midnight (there's no way this time or any time close to that could be legitimate in my case) then it gets bucketed to unknown.
I have tried to make use of the inherent unknown member, but it seems kludgy to me in its practical application. Not that I'd be closed if someone could show me how to make it effectively work, as it would have the advantage of always being at the bottom of the list. I've read it's not as high performing as an actual unknown bucket, but that could mean nothing in human terms.
I've also seen unknown codes combined with the word Unknown, as in Unkown Code: XYZ. This does have the advantage of identifying what is unknown, though there's more to implement.
Well, missing temporal values should probably not be getting selected for any kind of dimensional analysis anyway, as that just skews reality, messes with averages, etc. Identifying unknown values is not the objective of dimensions in the first place. Just because you can, and some brilliancy prize winner says you should, doesn't mean it's either a good idea, or necessary, at least for temporal data. I would not be all that fond of finding NULL values in a data warehouse, as that might suggest it's being mis-used. Given the costs thereof, I'd be very suspicious about the fiscal benefit.
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
November 1, 2017 at 1:37 pm
RonKyle - Wednesday, November 1, 2017 1:31 PMthe DST thing disappear entirely. Nothing but a PITA, and that's being generous.
Gives us more daylight in the evening during summer instead of in the morning when most people are still asleep.
Hmmm... so we inconvenience everyone because some considerably smaller number of people refuse to adjust to reality? Nahhhhhh... no thanks...
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
November 1, 2017 at 1:48 pm
RonKyle - Wednesday, November 1, 2017 1:31 PM
the DST thing disappear entirely. Nothing but a PITA, and that's being generous.Gives us more daylight in the evening during summer instead of in the morning when most people are still asleep.
Hmmm... so we inconvenience everyone because some considerably smaller number of people refuse to adjust to reality? Nahhhhhh... no thanks...
Not trying to convince, only pointing out that there is a reason. Whether that reason warrants the extra trouble I will leave to everyone's own opinion. If enough people want it ended, it would end.
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply