• RP_DBA (3/8/2013)


    The discussion I was involved in didn't key on messy, poorly performing code but rather on routinely taking shortcuts and not following best practices.

    Depends on the best practice. I routinely omit RI for example because I find it frustrating down the road a lot of times. I use it only when it's absolutely required.

    However...

    Things like data types not matching underlying tables,

    Okay, THAT'S lazy.

    using "SELECT * INTO #TblName"

    Guilty, depending on circumstances

    , and omitting even the simplest of comments in multi-step processes (pet peeve).

    Also guilty. Most T-SQL is self explanatory. The only time I put in comments is when I feel the code doesn't explain the reason. Most of my comments are about the business reasons really odd algorithms are required, not about the code itself. If I'm breaking established patterns or obvious coding techniques I'll also comment for the reasons so if someone inherits it they don't just remove it when I did it for optimization, not clarity.


    - Craig Farrell

    Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

    For better assistance in answering your questions[/url] | Forum Netiquette
    For index/tuning help, follow these directions.[/url] |Tally Tables[/url]

    Twitter: @AnyWayDBA