• andrew.morrell 67746 (1/3/2014)


    DBAs and Developers are at times both purists but I find that developers tend to be a little more pragmatic in allowing some things to wait until a refactoring exercise.

    For DBAs though it is a little different as they work a little more isolated from the end users and know that a mistake or shortcut early on can (and often will) lead to a serious time cost later on in reworking a schema.

    Education is key so that both parties understand where each comes from. Decisions need to be made together and where necessary arbitrated by an architect or third person who is neither a dev or a DBA.

    I am a dev though so maybe my impression is a little skewed?

    More communication and less criticism is the key as we are all working to the same goal - aren't we?

    That's why I sit right smack dab in the middle of the Dev Team and encourage them to ask me a question if they have any doubts about something they're working (and I'm close enough to everyone to overhear potential problems, as well). I also do 100% peer reviews that frequently turn into mentoring sessions, conduct "Lunch'n'Learn" training, and have published standards and "Tips'n'Tricks" published on the internal Wiki.

    --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)