Mandatory SQL breathalyzer test

Today we've spent a lot of the day in discussions with some folks about developers vs. DBAs, and how it's often the case that the two don't work together. Developers need to know the effect of their design choices on the database, and DBAs need to educate the developers. There should be a close working partnership between the two but bad communication and ignorance often get in the way – the DBAs don't know what the app devs want from them, and the app devs don't understand *why* the DBAs are so protective of the data tier. Neither side understands the day-to-day challenges of the other. Misunderstanding breeds conflict breeds animosity breeds intransigence and uncooperativeness. One of the eye-opening things sometimes is teaching DBA stuff to developers and vice-versa so they see the challenges and technology choice implications both ways.

We were pointed to this spoof video about a DBA-dev confrontation – http://www.benhblog.com/2009/03/linq-dba-vs-developer.html – pretty funny.

Kimberly was trawling around on that blog and found a quote: "I was surprised to learn that EF decided that since there was not a primary key it would just use all the non-nullable columns as a concatenated primary key.  This might not be what you want." (where EF = Entity Framework)

Woah! Talk about the absolute worst key, and it does it automatically as the default! Kimberly blogged (see Seriously, are you kidding me?) about why this is bad, so I won't repeat that here – although as you can see it's set us both off on rants.

And that's why sometimes you can understand why the DBA doesn't want the developers anywhere near the database without taking a SQL breathalyzer test first.

4 thoughts on “Mandatory SQL breathalyzer test

  1. Another comment I get from developers is "I can do it in development, so I can do it in production to; we don’t need "SQL" DBAs (yaa they like Oracle more :p)". I have such hard time explaining to them that in Development if something goes wrong they affect only themselves and internal staff. In production something goes wrong I got exec calling me because the Minister is screaming at them heh.

    Good Video heh :).

  2. I heard Kimberly on RunAs radio discussing this topic. I think part of the problem is the title DBA, it’s a single title with multiple meanings.

    Internally we’ve had this discussion many times when creating job postings. We really want a database developer and not an Administrator – we build software for sale. It’s also interesting the difference between platforms (Oracle vs Microsoft). Years ago we put out an ad for an Oracle DBA and the majority of the applicants were just that… administrators – experts in managing backups, riding herd on tapes, and monitoring for bads stats/indices. Not a developer in the bunch ("yeah I’ve seen PL/SQL – but haven’t had to use it much"). The same posting on the MS side would bring in more hybrid people with a strong slant towards development and weak on the administration side (they had trouble answering "please describe a good backup/recovery plan" – however they were able to write a stored procedure).

    What’s a good title for each of the two roles?

  3. If "Neither side understands" then may be invite intermediary.
    In some firms there are DBA(s) in development department. They are connect with other DBAs which not in development department. I am such man. I understand both sides, because I have more then 10 years experience as Oracle developer and DBA. Last time mainly as developer.

Leave a Reply

Your email address will not be published. Required fields are marked *

Other articles

Imagine feeling confident enough to handle whatever your database throws at you.

With training and consulting from SQLskills, you’ll be able to solve big problems, elevate your team’s capacity, and take control of your data career.