MySQL RANT

[markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org (markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org)]

> Date: Thu, 07 Jun 2007 14:34:54
> From: John Chambers <jc-8FIgwK2HfyJMuWfdjsoA/w at public.gmane.org>
> Subject: Re: MySQL RANT was: PVR or DVR for Linux - NOT MythTV
> To: <discuss-mNDKBlG2WHs at public.gmane.org>
> Message-ID: <20070507143454.32402.jc-8FIgwK2HfyJMuWfdjsoA/w at public.gmane.org>
>
> Kristian Hermansen commented:
> | I could go on and on about software developers who ignore the nature of
> | databases. It drives me crazy. You wouldn't put up with a developer who
> | didn't understand or know the language they were developing in, why do
> | people put up with ignorance about databases if your application uses
> | them?
> |
> | I can categorically say that *any* software developer that chooses MySQL
> | without a very specific reason should be fired. The "good enough" excuse
> | is laziness.
>
> Hmm  ...   Using  the  same  approach,  I might say that any software
> developer that writes a shell script rather than a  "real"  scripting
> language  like  perl or python is lazy.  But I'd have to admit that I
> write simple shell scripts all the time. Granted, when they get to 10
> or  12  lines,  I usually start thinking "This would be better in p*"
> and add the punctuation chars to  turn  it  into  the  more  powerful
> language.

That is a fundamentally failed analogy. You are comparing different
approaches to a single problem with a single approach to a specific
problem.

The choice of bash, python, C, etc. are how you choose to solve the
problem. In the case of choosing a database, the choice on how to solve
the problem has been made. Further, it now takes knowledge of the tool-set
of the solution to choose correctly.

In a professional environment, if you ignore the body of knowledge and
theory about the tool-set to your solution, I maintain you should be
fired.

Even further, without a very specific reason, the choice of using MySQL
shows a complete lack of understanding about SQL databases, and that may
pass these days for beginners, but not for competent software engineers.

>
> Larry Wall has pointed out that laziness is one of the attributes  of
> a good programmer, and used this as a primary argument for perl.  Why
> do something the hard way when there's a tool that lets you do it  in
> a simpler way? The fact that a tool isn't general purpose and doesn't
> do a lot of other jobs isn't actually a very good argument if  you're
> trying to get one job done with a minimum of human effort.

There are lots of people to whom people listen when in fact they should
not.  There is a reason why perl is mostly used only for things like admin
tools.

>
> I mean, I know C well enough that I haven't consulted a C manual  for
> a couple of decades, but I don't write much my software in C. Most of
> the time,  I  use  more  complex  languages  like  perl,  or  simpler
> languages  like  the Bourne (again;-) shell.  And sometimes I need to
> hit a problem with a  powerful  language  that  makes  low-level  bit
> twiddling easy, so I use C.

Again, you are confusing the choice of the appropriate type of tool for
the job, with choice of the most appropriate tool of a particular type.

The decision process is completely different.

You do not choose between a corvette and a truck to haul lumber. You
choose the best truck for the job.

>
> This seems to be the heart of the argument for mySQL. Not that it's a
> good  tool  for  everything.  Just that it's good enough for a lot of
> things, and when it isn't, you can use something else.

And it is a flawed argument for the above reasons. The "only" reason
people can come up with is that it is "good enough," but that requires
some understanding and quantification of "enough" that I submit has not
been achieved.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.