• (cs) in reply to chubertdev
    chubertdev:
    Mr. AHole DBA:
    Kyle Huff:
    The DBA should have fixed this by declaring an index on the UserLoginName column. No code changes necessary.

    Also, someone should point out to Merle that they are using Firebird and therefore there's no such thing as SCOPE_IDENTITY().

    And if the table is highly concurrent and huge? Also, why are the DBAs looked to provide band-aids for developer mistakes? It's as if the DBAs are the 'garbage collection' for the devs implementing worst-practices.

    How about you fix your code so it doesn't suck and fits to the standards of a experienced developer instead of creating potentially massive IO, wasted memory, another index to be maintained every single time the base table changes, and more options for the query optimizer to review?

    The problem is that there are a lot of DBAs who have the attitude shown by people like you and JJ from today's story, but most of them have the skills of JJ, rather than someone like you who can actually back up and justify what he's saying. I've been lucky to put myself in a position to work with more people like you, but from what I've heard about in this industry (these sites, user group meetings, etc), there are a lot of DBAs who will do something a given way "just because", and that's not acceptable. They would have probably produced a blank stare after reading your second paragraph.

    That being said, there are a similar number of developers who act this way, but it's a bit different. DBAs go into the front end code far less often than developers touch the databases, so I can understand that DBAs are a bit more defensive of their territory.

    Do note, I am hamming up the character of Mr. AHole DBA Alpha Nerd but yes, a lot of us do exist and I find myself in that crowd too.

    NOW TO DRINK MORE DEVELOPER TEARS!!!!

  • (cs) in reply to Mr. AHole DBA
    Mr. AHole DBA:
    Do note, I am hamming up the character of Mr. AHole DBA Alpha Nerd but yes, a lot of us do exist and I find myself in that crowd too.

    NOW TO DRINK MORE DEVELOPER TEARS!!!!

    You definitely need a water bottle with that label.

  • Monty (unregistered) in reply to darkyuris

    Data is the most important to a business. Everything else can be bought, rewritten or otherwise reacquired. But your data is YOUR data and cannot be sourced elsewhere.

  • Valued Service (unregistered) in reply to Mr. AHole DBA
    Mr. AHole DBA:
    The Balance:
    I think the number of poorly trained people who drift into becoming sysadmins and DBAs generally outweighs the number of poorly trained people who drift into becoming developers.

    The difference however, is that the well trained developers can usually do the job of a DBA, whereas well trained DBAs wouldn't know the first thing about development.

    Dog:
    Most DBAs couldn't code their way out of a wet paper bag. Most DBAs I've worked with are arrogant, stupid, and a fucking pain to deal with.
    Dog:
    That's because it was written by a fucking DBA with the brain capacity of a toadstool.

    Dog: That's a fitting name for you. I suggest you keep it, perhaps add 'female' to the front of it to make it more accurate... you know, focus on data quality.

    It's time to feast on crying developer tears, this is my favourite part on this site. Today is a especially good day, as the developer tears seem to be emitting from plump newborn babies, making it akin to eating 'develop tears veal'.

    Ok crying developers, as you overfill my cups with your delicious tears, realize a couple of things:

    1- You are agreeing with your favourite whipping boy, Nagesh. Full stop. That alone should make you question your existence, but let's continue on.

    2- The more you cry and scream, the more obvious it is that you aren't a big time developer and probably worked in mid tech boring ass shops without a major tech department to put your ego in the trash bin where it belongs.

    If you SERIOUSLY feel that a developer can do the job of a DBA, you are working in the most simple of environments and always have. It is rather comical watching you guys think you know what being a DBA providing 5 9's uptime (most of you don't even know what that means and have to google it, you're so far removed from operations), in a highly concurrent environment (read over 5000 transactions per second per DB), on data sets terabytes upon terabytes, and that's just on the SQL Relational database side! You think you could handle a Hadoop or Google Elastic search digesting hundreds of gigs a day and handle all bottlenecks along the line?? LOL. The ego and delusion here is off the hook.

    3- The crying about not having access to sensitive data or environments, shows a complete lack of understanding of security policy on the enterprise, federal, payment card or finance industries. It means you have worked in a shop that doesn't really have anything that anyone really wants, writing apps that no one really cares about as it really has no exposure.

    Please, do continue to cry more. You fillith thy cup.

    Problem solving is a shared skill.

    Therefore, everything else is domain knowledge and can be learned.

    The VAST majority of the problem in development (DBA or programmer), has to do with:

    1. Lack of due diligence with training and researching solutions.
    2. The amount of bad knowledge available on the internet.

    Once you have setup good access to good information, you can learn the domain knowledge and work your way up to skillfulness.

    For anyone that doesn't have the knowledge of those two problems (researching, and knowing bad knowledge exists and how to identify it), they will never get past horrible, and be a pain in the neck for everyone else.

    Now, a problem that cannot be avoided, is when there is a strong consensus from your source of knowledge that is just plain wrong. If you hit one of those, you could be using a bad technique for years, or your whole life.

    But the biggest problem I see here on both sides of this debate...

    <<<< EGO >>>>

    It's just too dang big to avoid tripping over yourselves. Some good curt honesty will work towards reaching a common ground.

    There are bad DBAs, bad developers, and just plain bad workers, on all sides of this ridiculous fence. Get over it.

  • (cs) in reply to Monty
    Monty:
    Data is the most important to a business. Everything else can be bought, rewritten or otherwise reacquired. But your data is YOUR data and cannot be sourced elsewhere outside of the NSA.

    FTFY

  • The Crunger (unregistered) in reply to chubertdev
    chubertdev:
    faoileag:
    why not simply do a "set @tempid = (select max(UserLoginName) from user_table;) + 1"?

    It takes an IQ of roughly 70 to understand that MAX+1 is bad. I've seen someone fired for using it.

    The post is chock-full-o WTFs even for those of us with the IQs of a slug. But please explain how you can get fired for applying an operator to the entire table, but not for applying it to a (possibly insufficient) subset?

    Bloat-a-saurus:
    Um... Why leave the previous code still commented in?

    Because 60% of the WTFs reside in the original code. Magic numbers, horrendously bad design for a stored proc, a hidden race condition, treating more than one match the same as no matches.

    "Just a developer" did a pretty good job of reverse engineering the bad behavior of the original code, with the exception that:

    (1) the original proc will stop counting whenever multiple records have the same user number, since it treats multiple matches the same way as no matches (2) the replacement proc sets an upper bound on the user number, which means it will stop counting once a record with that user number is created (3) the faster version of the stored procedure may expose the race condition that had been masked before ("bring back the while, just start at a higher magic number, please!", (4) even the uber-smart DBA code reviewer didn't notice that the new code fails when no records exist with a user number in that range

    The CAPTCHA says it all: nulla

  • Norman Diamond (unregistered) in reply to Valued Service
    Valued Service:
    The VAST majority of the problem in development (DBA or programmer), has to do with: 1. Lack of due diligence with training and researching solutions. 2. The amount of bad knowledge available on the internet.
    Bad knowledge is available everywhere. Some comes from vendors, some from managers, some from colleagues, some from customers, some from everywhere. When MSDN came on CDs around 75% of its pages were accurate, maybe the same proportion as now.
    Valued Service:
    It's just too dang big to avoid tripping over yourselves. Some good curt honesty will work towards reaching a common ground.
    Bzzt, wrong. Some good curt honesty will get you fired. That's half the reason this site exists.
  • (cs) in reply to Norman Diamond
    Norman Diamond:
    Valued Service:
    The VAST majority of the problem in development (DBA or programmer), has to do with: 1. Lack of due diligence with training and researching solutions. 2. The amount of bad knowledge available on the internet.
    Bad knowledge is available everywhere. Some comes from vendors, some from managers, some from colleagues, some from customers, some from everywhere. When MSDN came on CDs around 75% of its pages were accurate, maybe the same proportion as now.

    I'd say that #2 isn't the majority of the issue, simply because bad programmers do not do research.

  • Norman Diamond (unregistered) in reply to chubertdev
    chubertdev:
    Norman Diamond:
    Valued Service:
    The VAST majority of the problem in development (DBA or programmer), has to do with: 1. Lack of due diligence with training and researching solutions. 2. The amount of bad knowledge available on the internet.
    Bad knowledge is available everywhere. Some comes from vendors, some from managers, some from colleagues, some from customers, some from everywhere. When MSDN came on CDs around 75% of its pages were accurate, maybe the same proportion as now.
    I'd say that #2 isn't the majority of the issue, simply because bad programmers do not do research.
    Sure they do.

    Some copy nonsense from Stack Overflow. (There's a lot of good stuff on Stack Overflow, but there's a lot of users who can't distinguish the good stuff from the bad.)

    The programmer of Sony's rootkit even knew that OSR would be a good place to go to ask someone to pls send teh codes.

  • (cs)

    Those are the ones that I would consider slightly above the bottom of the barrel. They are smart enough to do research, they just do it poorly and blindly.

  • FieryBalrog (unregistered)

    Do sequences not exist in T SQL? Oracle dev here.

  • gumby (unregistered)

    "sigh".

    Ugh... A good portion of the SQL Server "DBA" people I've worked with did not know about scope identity, and promoted "select max(id)+1" as the 'proper' way to do it. When I'd point as (as just a 'developer') the notion of race conditions and select max() being hacky and error prone, I'd get a nice pat on the head and told to go back to my code.

    Maddening...

    Same people that didn't understand the need for pagination in an app, and promoted crappy stored procedure hacks full of select top() BS to get the middle 50 rows out of 20,000 results. But hey, wtf, it's 'enterprise', right? No one expects it to be efficient...

Leave a comment on “The Fix”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article