MySQL RANT
markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org
markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org
Fri Jun 8 14:41:54 EDT 2007
> 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.
More information about the Discuss
mailing list