On Mon, Jan 18, 2010 at 3:53 AM, I Dream in PHP < hypertextpreproces...@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.
_______________________________________________ New York PHP Users Group Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk http://www.nyphp.org/Show-Participation
