NYCPHP Meetup

NYPHP.org

[nycphp-talk] MongoDB and others, convince me. :-)

Justin Dearing zippy1981 at gmail.com
Mon Jan 18 08:57:56 EST 2010


Gary,

A cross specialized dba will not be out of a job with mongo, but a sql
admin will. Your perspective (shared by me) is hard to see for those
who are married to their specialities.

However, I will add one caveat to your statement. When a system gets
to a certain size, it behooves the IT team to segregate dba developer
and admin roles. From a change management perspective it creates
barriers that simplify documentation and auditing.

Justin

On 1/18/10, Gary Mort <garyamort at gmail.com> wrote:
> 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.
>

-- 
Sent from my mobile device



More information about the talk mailing list