Post reply

Do you have DBA syndrome?

  • October 6, 2016 at 9:03 am

    #1905202

    Gary Varga (10/6/2016)

    Jeff Moden (10/5/2016)

    ...I do have to sometimes say "NO" to something but I'm normally able to suggest an alternative and the reason why the alternative is better...

    I don't understand why people don't realise this is just an expanded process of what we all SHOULD be doing internally anyway.

    I suspect most, if not all, of you will evaluate a few options before even considering discussing with anyone else. I doubt I would be alone in feeling annoyed when someone comes to ask your opinion without even attempting to evaluate and assess the problem and potential solutions. In my opinion, I would rather discuss possible alternatives with someone who thought about it but didn't come up with a solution than someone who could come up with a solution (appropriate or otherwise) but could not be bothered to try.

    Couldn't have said it any better than what you did, Gary. Especially that last part.

    --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)
    Intro to Tally Tables and Functions

  • October 6, 2016 at 5:54 pm

    #1905298

    I do have to sometimes say "NO" to something but I'm normally able to suggest an alternative and the reason why the alternative is better.

    This is what a DBA should do in anything that has to be in contact with the database, it's a much better setup than just saying no to something that is new, just because it is new. Well, as developers, we will, we should be testing the stored procedure, the views or the triggers which we would want to be used in a system which connects to a database, but saying no immediately? without even suggesting something? the hell with your work.

  • October 6, 2016 at 9:37 pm

    #1905309

    joshua 15769 (10/6/2016)

    I do have to sometimes say "NO" to something but I'm normally able to suggest an alternative and the reason why the alternative is better.

    This is what a DBA should do in anything that has to be in contact with the database, it's a much better setup than just saying no to something that is new, just because it is new. Well, as developers, we will, we should be testing the stored procedure, the views or the triggers which we would want to be used in a system which connects to a database, but saying no immediately? without even suggesting something? the hell with your work.

    Careful now... If you try something new and want it to go to production right now and without investigation, then double the hell with your work! 😉 The DBA is responsible for the safety of the data, the safety of the server, and even your safety even if you don't believe that. You're not responsible for any of those things... even your own if you regularly jump the gun.

    If you're smart, you'll check with the DBA and maybe even write some accuracy and performance testing to sell your idea.

    Also remember that there's a whole lot of responsibility on your part to know the tools that you're using. Also remember that a good DBA will be well ahead on the power curve on a lot of new features. What may seem like the DBA not even giving something a chance might actually be caused by the fact that they've already tested it for accuracy and performance and it failed one, the other, or both. The original renditions of MERGE and the current rendition of FORMAT are just two of the dozens of things you might not know about when it comes to problems.

    Now, with something like that, I'll usually take the time to send an email to the Developers saying "Don't use the shinny new bobble because...", but we don't always have the time and if you're the 10th Developer to ask me, I'm going to be a bit short because I've explained to 9 other Developers in the same group and not one of them told the others.

    Remember... team work and effective communication amongst yourselves and others may save a whole lot of "the hell with your work". And also remember... the DBA is also trying to save your skin, as well, even if it doesn't look like it.

    With that in mind, come to my shop and tell me we need to setup SSIS and Hadoop for the kind of stuff we're doing. I'll make sure that you never step foot in the building ever again. 😛

    --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)
    Intro to Tally Tables and Functions

  • October 7, 2016 at 12:53 am

    #1905318

    Jeff Moden: Most of the time, much of that happens before anyone writes any code because <drum roll please>, we're a team and we bounce ideas off of each other. I rely on the Developers and much as they rely on me.

    Thank you Jeff, nobody need to be enemies just because they do different jobs. I wish I had you working with me because I know I would learn a lot from you!! Take a bow everybody!!

    Manie Verster
    Developer
    Johannesburg
    South Africa

    I am happy because I choose to be happy.
    I just love my job!!!

Viewing 4 posts - 31 through 33 (of 33 total)

You must be logged in to reply to this topic. Login to reply