I often find myself in an odd position. I think of myself as a developer, or more precisely an Oracle database developer. I used to be an Oracle developer, but then they got involved in ADF (which I leave to the likes of Chris Muir) and I suspect Java will dominate more in future. The OCP track emphasizes PL/SQL development though I like the thought of the "SQL Expert" exam. I've done Oracle Forms work too, and that is distinct from PL/SQL development too even though it also involves writing PL/SQL.

However I work for a consultancy and am in the "Application Development" space, mostly inhabited by Java and Dot.Net people. They have this perception that anyone who understands a database is a DBA. The concept of a "database developer" is alien to them and somewhat repulsive too, I think.

I'm not a DBA. I've done a couple of roles that involve very basic DBA tasks, like installing a database and creating tablespaces. But I couldn't look someone like Nuno in the eye if I claimed to be a DBA. Pythian employs DBAs. Most of the attendees of the Sydney Oracle Meetup are DBAs. They use OEM and RMAN and Grid things and know about ASM and log shipping, DR and replication. I'm not one of them.

A few weeks back the "Database" proposal for StackExchange got renamed at the last minute (ie after people had committed it) to "DBA". Again, it pushes the concept that anyone who knows anything about databases must be a DBA. Don't get me wrong. Most DBAs do know a lot about databases. It would be nice to say 'all' but as a DBA knows there's a big difference between three nines and five nines and you'd never say 100%. But not every database expert is a DBA.

So I'm a bit concerned about my 'space'. The current TIOBE index has PL/SQL down at number 25 with less than a 0.6% rating. A little over a year ago it was at 0.9% I'm not convinced of the validity of the measurement, but I don't know of a better one. It again suggests a de-emphasis on "database developer" as a role although Transact-SQL had a big jump.

I'm spending some time trying to understand Java. Not specifically the code. I've worked on a few small Java programs and individual programs are relatively easy to understand (or they should be). Its how they all fit together in an application that is tricky. Currently I'm in the phase of wondering why there's so much configuration involved, but that may well be because there is proportionally more config for a small app than a big one.

11 comments:

Our backgrounds are a lot alike and I find myself in the same spot. Database Architect seems to be the sweet spot and, to me, it's sort of "a senior developer who knows some dba stuff and can do data modeling". Database Architect is faster to write.

I've always been a DBA/Developer and I've always thought they complement each other.

The majority of tuning ends up being SQL tuning, rewriting PL/SQL, or converting .NET and Java to PL/SQL so it can actually perform. These are all tasks much better suited to a good developer than a DBA, yet they are deemed DBA work. Never understood that myself. :)

I wouldn't worry too much about the TIOBE index. PL/SQL is never going to be a "mainstream" language like Java or .NET, but as far as I can tell it has carved a solid niche for itself out there in the real world.

The SQL, PL/SQL and Application Express forums are the most active forums on forums.oracle.com, only surpassed by the "general database" category.

The numbers for Apex have never looked better: http://joelkallman.blogspot.com/2011/01/is-anyone-using-oracle-application.html

That said, I work in a big company and there's only a handful of us crazy people that actually use the database for more than "create table foo" and "select * from foo".

Each to his own, I guess. You might want to show this to people who wonder what a "database developer" is:

I constantly ask myself: "am I a DBA or a Database Developer"? My title is officially DBA, which I thought awkward at the time I started my current job, when my background clearly shouted "Database Developer", IMO. But I've become used to the title over time and I don't mind it.

I think lumping anyone who works mostly with a database under the "DBA" umbrella is like lumping all developers, software engineers, etc. under the "Programmer" umbrella. Not very descriptive, is it? And may even convey something your not.

When asked what I do for a living, my answer varies. I might say "DBA" if I think they know what that means. If not, I'll says "Database Administrator". And if I think they have no clue what that means, I'll say "Software Engineer" or "Database Engineer".

For me, I prefer "Database Engineer' over "Database Architect" since (1) my degree is in engineering and (2) some (clueless) people will automatically think of buildings and scratch their head. I make things work - I'm an engineer.

I thought it had all been reduced to "best practices" and rabidly clicking on a Grid screen - while praying it won't create 600 sessions behind the scenes while "monitoring" its own database!

Maybe I was wrong? (or was it someone else?) ;)

Wouldn't waste 5 seconds with the TIOBE nonsense: another meaningless ratio that can be manipulated to show anything.

All Apex users need good SQL and PL/SQL developers. Same goes for just about any DW/BI installation.

I doubt that Java by itself will be around much longer (for the "foam-at-the-mouth" rabid apologists, read the latest entries on the subject: that j2ee you spent so long trying to spell is basically gone!).

It will survive in the phone and pad platforms with their own toolkits, and as a tool to make monster "enterprise software" packages with "cast of thousands" development teams in third world countries. Which will only be used in outsourced sites because no one in their right minds would run them in-house!

Outside of that no one would waste time with java: .Net is the way to go and has been for more than 5 years now, only the java nutters at Oracle haven't realized it yet. :)

Then again they have their cart to push, haven't they? Damn, if after all the vociferations of the last 10 years someone pulls the rug from under their feet, all that "fusion" nonsense is gonna look pretty silly...

Quite frankly, the "death of the SQL-PL/SQL developer" sounds exactly like the "death of the DBA" thing: a whole pile of steaming s**t...

I prefer the thought of being a database engineer over and architect. I'll probably do a follow up post on those.

I think organisational structures play a part in the DBA / developer relationship, and I don't think they help. Most places I sit put the DBAs in with the Sys Admins and Infrastructure type people, but align developers to applications and business.

Gary, all developers need to know more than one language. The skills you pick up in one will help you be a better developer in the others. The same is true of DBAs .

Your comment about Java configuration is spot on. Most J2EE developers spend most of their time in XML files, mainly because they control more of the application logic than the Java code.

As for Noon's troll about .Net I'll leave that to others. My observation is that you can get bad applications in any programming lanaguage/framework/bloated corporate toolset. The only way to build decent applications is to use Python ;-)

I've been warned about calling it J2EE. Apparently it is now just JEE as they've fixed a lot of the old broken stuff.

Well, I say fixed. They've added this concept of annotations which I'm trying to get my head around."Annotations do not directly affect program semantics, but they do affect the way programs are treated by tools and libraries, which can in turn affect the semantics of the running program. Annotations can be read from source files, class files, or reflectively at run time. "

My interpretation of that is that there is a whole set of interactions which happen by magic rather though the obvious interface. I suspect this will keep Java programmers working for years.