Prod DBA 2.0 says no**

Dominic Delmolino has made a welcome return to regular blogging and it’s good to see that I’m not the only one forgetting the basics.

In the body and comments of Dominic’s*** first few posts back, the subject of database development is very much in focus.

So, DD got me thinking and here is my stream of random ramblings – they jump about a bit, it must be a Friday.

Production DBAs have no place on most development teams!

When was the last time you saw a production DBA in a scrum standup? (Genuine question – do you do that?).

Today’s production DBA is a busy man whether he’s 0.x (seen a lot of these), 1.0 (met a handful), 2.0 (heard tale of a few) ­čÖé

Some might say they’re too busy coming up withinsane “policies” and standards.

At the very least, even if he has automated everything that he can automate(*), with the vast estate of DBs that a small, modern production DBA team *should* be able to support, the ebb and flow of urgent production issues means that he’s unsuited to the predictability of the resource availability that modern agile project development demands.

That vast estate of DBs that a small, modern DBA *should* be able to support also means that the knowledge that the production DBA of any one specific application or schema tends to be very limited.

However, for most enterprise-level data-centric applications (caveats and clarities due to previous sweeping statements), the data model is still so important and it’s just not being done right in so many places.

Here is a link post to a selection of other writings on the subject.

What Dominic D says strikes a chord with me. (But I’ve got a vested interest. The role he describes is essentially what I do or what I try to find.)

Most agile development teams (caveat again – most agile development teams developing enterprise-level data-centric applications) need access to a database development specialist.

Someone who knows SQL, knows PLSQL (in the case of Oracle), knows performance and knows the features and functionality of a database ideally to at least the same level expected of a production DBA (albeit with different peaks and troughs in specific areas) but without the irregular demands on their time from urgent priorities.

Most of them need this to be able to build data models that scale.

And to keep everyone on track with the data model and the big data picture – this can quickly get lost in translation especially with commodity developers (plug and play).

Most of them need this to write or at least QA SQL and PLSQL that will scale.

Most of them need this to strike a balance between new features and stability.

Most of them need this as a regular interface to the production DBAs as a communication conduit and filter, and to uphold the requisite standards and policies for development to move into production.

And absolutely this database specialist should take full responsibility for what goes into production – it’s all about control and responsibility.

Two other thoughts occur (and I’m not sure I’d finished on the previous thought but it’s gone now, flushed).

Firstly, and I commented this on DD’s blog, there is belief that all developers are equal and that you can plug and play any developer into any project without any consequence. I don’t believe at all in this approach. I’ve never seen it work effectively apart from in the presentation layer – i.e. coding input fields and buttons, etc – and even then I’m far from convinced.

What I am definitely convinced about is that this in no way works for any layer that requires significant business knowledge and goddamit does that include the database.

On the subject of the second of the two thoughts mentioned above, the phone rang before I could write it down and so that thought has now disappeared. If I remember, I’ll update this. Until then my mind’s gone blank….

Oh yes, the second thought. Development DBA is sometimes the starting point for a junior DBA – en route to the production DBA. This is a nonsense given the control, responsibility and knowledge required. As mentioned they need to know at least as much as the typical production DBA.

*I’m not a production DBA. Never have been. And although I’ve thought about it, not sure I want to be. Development’s where it’s at for me. But how DBA teams have much automated? And automated well? Everywhere I’ve been recently, the DBAs are firefighting constantly. Or they’re refreshing environments. Or they’re just completely overloaded with stuff that sounds like it should be automated. I mentioned this to someone else recently and they commented that it was because a large percentage of the production DBA team were contractors and has no vested interest in automating. I don’t know if that’s true. Any thoughts? There should be no greater compliment than going into a company and improving it to such an extent that the manual intervention you were providing was no longer required. But I can see the conflict.

**Prod DBA 2.0 says no -> Not sure how many, people outside the UK are familiar with Little Britain. Think it was way overhyped myself, followed by way overplayed. Personally (as comedy appeal always is), although there have been exceptions like the Armstrong and Miller fighter pilot sketch, there’s not much sketch comedy that has regularly and consitently tickled my fancy in the last decade since the Fast Show.

*** Confusing – am I referring to Dominic Delmolino or have I taken to the convention of referring to myself in the third person.Did you know that the latter is known as Illeism? I didn’t.
Stylistic device or a form of narcissism?
My CV is in the third person and I’ve never been even 83.2% happy with that approach.
But I’ve never liked it when I’ve rewritten it with a personal pronoun – “I” – neither with the modern trend of no pronoun whatsoever, e.g. “Worked on an oil rig. Implemented XYZ. Put out lots of fires.”
It stems from my time at a consultancy – that was their style.
Then again, I don’t agree with the narcissism interpretation (e.g. a bit like celebrities and some sports persons).
If anything, for me at least, it’s completely opposite – a form of anti-narcissism, a self-demotion which I think of as being particularly British.
It can be easier to say “X achieved this” than “I achieved this” and maybe there’s a comforting distance between this CV character “Dominic Brooks” and myself?
Don’t know if there’s an established phrase of “take the blame but share the glory” but maybe it’s something like that …


Database Agility

A collation, for my benefit, of the thoughts of some others in this area:

Data modelling in the modern world

I first read Robyn Sands’s article on the importance of a good data model back when it was published in May.

However, the comments have since moved on and taken a life of their own – a sure sign of a great post – with some excellent points and poignant observations on the frequent neglect of the data model in the agile world.

If you’ve not read it or have not kept updated with the comments, then I urge you to.


I wrote a comment today on an article on meaningless keys on Chen Shapira’s blog, a comment that I subsequently felt was worth regurgitating in a blog article.

I would normally leave my comment as just that, the comment, but as I’ve also had a couple of similar discussions very recently, I thought I might as well digress off into a bit of a rant.

Chen was pondering the age-old dilemma of natural versus artificial keys, with particular reference to an older article from Jonathan Lewis.

Jonathan was highlighting one of the disadantages of meaningless keys where in his example a query on a table4 had to go back via table3 and then table2 to get to table1 to lookup the value of what could have been one column of a natural composite key on table 4.

This led Chen to wonder whether he was right or wrong to use a customer id rather than a customer name for his primary and foreign keys and he linked to a script to update natural foreign keys when those keys change.

You can find loads of articles out there regarding the pros and cons of natural versus artifical keys. As Chen points out, the storage overhead of using natural keys that are longer than artifical keys is rarely an issue.

Not so long ago, when I was preparing to leave a former employer, a fleet of robots ­čśë from a Big 5 (or however many there are these days) consultancy came in and looked at some of the data models, shook their heads and said something along the lines of “what are these natural keys here? we always use artifical keys” (throughout the models there were some artificial keys, some natural keys).

And again, recently, I’ve reviewed data model propositions proposing artifical keys where an immutable natural key was available … (actually on┬áreflection post blog post, I think this was a tendency to use another sequence id rather than a composite key of other artifical keys which is slightly different but still relevant).

(which almost brings me on to why non-database specialists trivialise the database and yet find it hard to string two tables together in an easy efficient way …

and which nearly brings me on to why agile teams seem determined to want to use people who all know a little bit of every application tier but not necessarily enough of each).

My take has always been to take a pragmatic solution.

Never say never. Never say always.

The candidates for a primary key should be immutable. They should not change, ever, period.

It’s ok for a unique key to change but…

A child’s foreign key references either the parent’s primary key or a unique key.

A candidate foreign key should also be immutable.

If it’s likely to change then use a sequence generated key.

And when designing don’t forget about how your data is going to be accessed (if you know that you’re going to want to access a table using a component of a natural composite foreign key, think carefully about that before making the queries go via a whole bunch of other tables just to lookup the value of a bunch of artificial keys) – Designers need to develop to validate their designs.