Top-notch mysql dbas?
Michael T. Halligan
michael at halligan.org
Tue May 18 16:37:51 PDT 2004
Hackers create themselves. Deadlines don't delay themselves just for
silly notions of idealism. That's the way it is. If you've got a year
to develop an architecture, you have a year to develop a system, not
a year to create talent, then a year to create a system.
This entire subject is silly.
> If they have that much money, why doesn't your customer -create- the
> expertise they need?
>
> I don't mean this in a pejorative manner. Where does expertise come
> from? Where did we all get our start? Many of us were UNIX
> administrators back when there were no courses on UNIX, or even C.
>
> Did we need Microsoft to teach us TCP/IP, or certify us as competent to
> calculate bitmasks? Of course not. We taught ourselves.
>
> What has changed? Only the industry has ossified; knowledge is still
> freely available, and people are still learning.
>
> Where do hackers come from?
>
> Because that's what you want; a MySQL hacker. Someone who will eat,
> breathe, and live MySQL.
>
> I think if you achieve some clarity on exactly what you want, this will
> enable you to better leverage your considerable assets towards locating
> the appropriate individual(s).
>
> Why not find some young bright kids and turn them loose to become the
> experts you need, with a salary scaled to well-defined benchmarks - that
> correspond to your organizational needs - so that they stay around to
> reap the benefits of their training? Take the money you have earmarked
> for paying your highly paid consultants and, instead, recruit some
> bright young people whose total focus is MySQL, and whose habits have
> not been shaped by other vendors' products? That's what you want, right?
>
>
> I mean, look. Where do you go to get MySQL training? Europe, that's
> where, because that's where it - MySQL - comes from. I've never met a
> quote-unquote 'trained MySQL DBA' in my life.
>
> Most MySQL DBAs seem to drift into it as a result of being the web
> administrator ... or the systems administrator ... but they are rarely
> adequate to their responsibilities, because their primary training, and
> primary area of interest, is not SQL ... it's HTML, or Javascript, or
> Perl, or shell, or C, or ... and their heart just isn't into it.
>
> Few web administrators have any appreciation for the beauty, or
> importance, of entity relationship diagrams ... and, you know what, not
> too many DBAs appreciate them, either, if the hundreds of
> poorly-designed databases I've seen over the past decade are any
> indication - it's always "add another disk controller", or "we need a
> RAID array" - kind of the whole dot-com phenomenon, in miniature. 'We're
> too busy to think.'
>
>
> In fact, there is a sharp divide between DBAs and systems administrators
> that is requires special training to bridge. They speak different
> languages ... and they exist on different levels. DBAs live in a world
> of abstractions, where the entire application is designed to insulate
> them, the DBAs, from the question of where, exactly, the data is ... and
> most of them prefer not to think about it. Systems administrators, on
> the other hand, live in a world of cables and devices, with software
> like a layer of frosting, to cover the ugliness beneath.
>
> This divide is aggravated by the disdain with which systems
> administrators are viewed, by DBAs - in fact, at Sybase, the RDBMS
> administrative login is, by default, "system", and DBAs are referred to,
> and refer to themselves as, systems administrators - leading to
> considerable tension and confusion, a state of affairs that , I
> sometimes think, must have been cultivated deliberately.
>
>
> Look, I've worked for a lot of different database vendors. Oracle, yes,
> but also Sybase, and also Ingres, and /rdb ... and I've also worked with
> MySQL. I know what I speak of.
>
> I'm not a trained DBA, by any means, although I have been trained in
> database administration. But, you know, databases are moving targets,
> and they differ enough from one another that keeping up with all the
> variations available with just one vendor is a full-time task. Just
> installing MySQL, a few months ago, I was struck by all the changes that
> had occurred in MySQL between when I had worked with it last, and the
> present version. But Oracle's no different. Triggers, table, row, cell
> locking, replication and a slew of other new technologies exist to
> differentiate each of the products from one another - and it is these
> extended behaviors that DBAs spend most of their time administering -
> not the core functionality.
>
> I've found it useful to consider a RDBMS as analogous to an operating
> system. As applications go, it is monolithic, and requires that the
> operating system be specially configured - as well as the hardware - to
> leverage maximum performance. It has its own logging, and its own user
> security, and its own filesystem, and its own superuser. Truly, it is
> like an OS within an OS.
>
> You're not going to find anyone who has training in MySQL amongst the
> systems administration community. This is not only because the training
> does not exist, but because hardened SAs tend to hate databases and
> prefer flat files - it is a cultural divide, 'K.I.S.S. versus Rube
> Goldberg' kind of thing.
>
> You're not going to find anyone who has training in MySQL amongst DBAs,
> either, by and large, because there are few DBAs whose expertise spans
> more than one database vendor - there's just too much difference. I've
> never seen a customer that maintained their data on multiple RDBMS
> products, either, so there's no opportunity for heterogeneous DBAs to
> evolve, generally speaking.
>
>
> If you'd like some help recruiting such people or if you'd like some
> assistance in resolving some very specific problems you may be having
> with MySQL, I'd be happy to help.
>
> One free tip: invite your candidates - not in the ad, but when you
> contact them - to select one book which they believe should be important
> to a DBA, from their bookshelf, bring it in, and explain why. This is a
> great way to separate the kernels of wheat that you are seeking, from
> the chaff.
>
>
> Regards,
>
> -- richard
>
>
>
--
-------------------
Michael T. Halligan
Chief Geek
Halligan Infrastructure Designs.
http://www.halligan.org/
3158 Mission St. #3
San Francisco, CA 94110
(415) 724.7998 - Mobile
More information about the Baylisa
mailing list