Friday, October 31, 2008

Don't Cramp My (SQL) Style ... Musings from an Oracle DBA

This post was inspired by a Twitter thread that took place on October 31st between myself, @oraclenerd, @dtseiler (maybe I only included Don for his tongue in cheek, playground banter), and @surfsearcher :
@oraclenerd: "besides commas at the start of a line (sql, plsql), I also hate mixed case sql and plsql"

@oraclenerd: "@piontekdd come on! it's just plain ugly...besides, I've gotta have have at least a little something to bitch about now and again. :) "

@piontekdd: "@oraclenerd life is too short to get upset about personal style :)"

@piontekdd: "@oraclenerd I like mixed case and see the validity in commas at the beginning ;)"

@oraclenerd: "@piontekdd well sir, I would argue that if you like commas at the beginning and the brewers, well... "

@dtseiler: "@oraclenerd I like commas at the beginning and the Brewers. Do we need to take this outside?"

@piontekdd: "@oraclenerd putting commas at the beginning (while not my natural style) is easier to cut and paste lines and to not miss commas.:

@surfsearcher: "@piontekdd the last dba i worked with corrected me on doing it that way, made me change all my sql b/c commas in front is "non-standard"."

@surfsearcher: "@piontekdd this dba was known for enforcing her personal standards to a point well beyond reason. i'm with you on the commas."


I believe the gist of what Chet was getting at was a personal style issue in formatting SQL or PL/SQL code:

select
foo,
bar
from
foobar
where
foo = 'BAR' and
bar = 'FOO'
order by
bar,
foo;

versus

SELECT
foo
,bar
FROM
foobar
WHERE
foo = 'BAR'
AND bar = 'FOO
ORDER BY
bar
,foo;



While I'm sure Chet was just venting over some work issues, it got me to thinking about standards in the IT workplace versus personal style. (Personal baseball tastes and my obvious over use of emoticons on twitter notwithstanding). I'm all for having coding standards, database object standards ... etc for in-house development. However, I do find that coding, whether it be .NET, Java, SQL or PL/SQL, has a bit of personal style to it. This does not mean making code difficult to read or impossible to follow, but I can see the need for some personal latitude when coding. I've experienced my own coding creativity slowed down by worrying too much about the standard and not enough on what I was attempting to solve. Is is not enough to provide excellent documentation and comments in your code?

I have worked as a developer on large systems (Oracle and C), as well as applications where I am the lone developer (Visual C++). On large system, it is important to adhere to some sort of standard to make the code easier to support by others. I've seen the proof that following these standards can keep maintenance costs down. I just don't see how forcing a developer to put a comma in a certain place, or using a certain case of letters, is going to hurt that.

I've been an Oracle DBA for over eight years. I've written my share of SQL and PL/SQL packages. I totally understand the need for certain standards. When designing data models for new applications, it is very beneficial to have object naming standards (tables, indexes, constraints, etc). It is important for developers to have a set of SQL guidelines. (e.g. Using bind variables where appropriate).

When I read @surfsearcher's tweet above, I started to get a bit passionate about writing this. I'm a DBA. At the end of the day, I'm ultimately responsible for what gets promoted to production and for the health of the database. However, my personal preference for where a comma goes shouldn't enter into the equation. It is my job as the DBA to work with the developers, not push my personal style down their throats. It is my belief that DBAs and developers need to work hand in hand in a collaborative way. If I ask someone to change something, I better have a better reason than "It is not standard".

I often see developers and DBAs engage in this 'us vs. them' relationship. I see this in online forums and lists. DBAs referring to developers as 'duhvelopers'. I've seen it in the workplace. DBAs are viewed as over-bearing, control freaks or where the DBA thinks their life would be easier without having developers. It does very little for making a better application. I've seen my share of 'duh' moments in the development life-cycle. I've seen my share of 'duh' moments by DBAs (myself included). I firmly believe a cooperative, open environment must exist for a successful application to be designed, developed, and deployed.

What do you think? Is there room for personal style when coding in the workplace? Can strict naming standards co-exist with personal style/preference? Is all this cramping your style?
blog comments powered by Disqus