One of the frustrations of data modeling is the regularity with which the same problems re-surface, and our propensity to tackle them from first principles (or no principles) rather than building on an understanding of established work.
Know the feeling? Go have a look at this must read article by Graeme Simsion.
http://www.tdan.com/i036fe02.htm
I'm starting to feel old. Not quite old enough to have ever had to program with punch cards, just old enough to remember the good old days of the command line utility. Yes I know that the command line is still alive and well today, what I am noticing on an increasing scale is younger people around me not even attempting to use, and learn about a tools if it does not come with a windows GUI.
aspnet_regiis, OSQL, bcp, net *, adsutil, csc, god forbid I’ve even worked with some juniors who didn't know how to use those old favorites copy, move, ren.
Over the next few weeks I am going to write several entries on how I use the tools readily available to everyone, more effectively. In summary I will show you how to work smarter not harder.
I consider these optimizations a value add to whoever is signing my paycheck at any given point in time. instead of getting someone who wastes a good portion of their day clicking, double clicking and wasting energy moving there hand between keyboard, mouse and... Maybe that’s another discussion. All that energy is much better spent walking to the kitchen for coffee and back. I guess what it comes down to is that the more effectively I can perform my duties the more time I can spend feeding my body the caffeine it requires on a daily basis.
I had the pleasure to see Graeme Simsion talk at the local SQL server user group last week. It was really quite enlightening to here some quite unique views on how as data modellers & as software architects we approach database design.
Here is an article written by Graeme in which he goes into detail on the points discussed in his talk.
An interesting article over at SQL Server Central using a recursive function to find the next working day. I can't help but think that this may be the wrong approach. Will have to sit down over the next day or two to work out if this can be done using sets instead of cludgy functions.
From http://www.sqljunkies.com/WebLog/knight_reign/archive/2005/07.aspx.
Why wouldn't you just cast the string to a datetime?
SELECT CAST('20050112' as DATETIME).
Seems like a lot of effort for no gain. Or am i missing something?