NYCPHP Meetup

[Gary Mort]

On Mon, Jan 18, 2010 at 3:53 AM, I Dream in PHP <
hypertextpreprocessor at dynamicink.com> wrote:

> Nobody else thought it was very revealing when someone shouted out "I like
> my job" (assumedly a DBA job) as a reason not to use NoSQL?! I love MySQL
> and NoSQL DBs certainly do not fit all projects, but in the ones where it
> does fit it saves a huge amount of development time and makes the
> dedicated-DBA position somewhat obsolete.
>
>
I don't follow this one.  How does it make the dedicated DBA job obsolete?

Here is my experience withy the DBA world[fill disclosure, I started as a
programmer, moved into Windows Admin and DB2 DBA, then moved to Lotus Notes
Admin and Programming, before moving into PHP/Mysql programming]

The role of the DBA is to keep the system running, to provide a check on the
developers who tend to throw any old query together and blame the network,
the os, or the database for their lousy performance choices, to recover the
system when it inevitably has some weird failure, and to provide a central
resource for all things data.

Programmers who butt heads with DBA's would rather just have them out of the
way so they can finish their work.  Of course, chances are that programmer
will be long gone when the crud hits the fan and so doesn't give a damn
about recovering from stupid choices.

Over the years, again and again I've seen the "this eliminates the DBA
position" - MySQL......Lotus Notes.....everything.   What they really mean
is that you don't need a DBA to start throwing code up and together and
rolling it out.

Plus when you have a small team of programmers....one of them becomes the
DBA in effect....doing the small bits of work for it in the initial phases
and providing that central check.

Where you store the data doesn't matter, you still need someone for all
those functions once your system achieves a certain level of complexity and
commercial value.  When having the system down for more than an hour is a
crisis.

Whether you need someone full time for that, or a maintenance contract with
a consulting team which built the system, is irrelevant - you need that
person there.  Monitoring, checking performance, catching problems BEFORE
they occur.

If all coders where like me...knowing a good bit of network admin, some
amount of systems admin, database admin, and programming - sure you don't
need that.  But my experience is that this is rare, most people specialize
in one of those skills.....which leads to a tendency for finger pointing
when things go wrong[it's the network...no its the system...no it's the
code....].  Of course, this always kept me busy with Lotus Notes
troubleshooting problems and implementing solutions when they cross
specialities[I especially would love the discussion where everyone thinks
the "ideal" solution is to fix the problem involving days of effort by one
person....when everyone also acknowledged that there were hour or so of work
arounds they could use to make it work.....but that required THEM to do the
work rather than pawn it off on someone else.  So they were all too happy to
cost the company days of manpower to avoid an hours work.]

Sorry....hotbutton here.  I suspect that the "wit" who responded that way
was not a DBA but a programmer speaking as if they were the programmer
stereotype of a DBA....and I have little patience for crap programmers who
only care about their code and are willing to torpedo the business rather
than follow a little process.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20100118/9d178f59/attachment.html>