Top-notch mysql dbas?

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