Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Thursday April 05, 2007
09:24 AM

Databases versus Programming Languages

[ #32916 ]

In response to a query from someone, I found myself explaining this (paraphrased):

You know I'm a Perl programmer. I teach the language, I sit on the Steering Committee of the Perl Foundation, I've been published on the language, yada, yada, yada. Despite all of that, I think the choice of the correct database is more important than the choice of programming language. Databases, even small ones, really are that important. Don't use MySQL.

If this guy said he was going to do all of his work in PHP (and he might), I'd be disappointed. If he settled for MySQL "just because", I'd be disgusted.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Databases versus Programming Languages 14 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Whatever lesson you learn there is always a more important one.

    Today I learned even if your going to use php and mysql never store monetary values in euro as a floating point. Actually I knew this already but I'm fixing something by someone who didn't.
  • If the answer to the question is "MySQL" you are not asking the right question. : )

    • If the answer to the question is "MySQL" you are not asking the right question. : )
      I see the smiley face, but MySQL has served Slashdot extremely well over the years. The proof is in the pudding, no?
      • Thank you for noticing the smiley face.

        I would have to agree here. MySQL has warts? Really? Sure it does. That doesn't mean it isn't useful in certain situations. MySQL would not have become as popular as it is if it was crappy and didn't perform well in the area it was designed to run.

        • MySQL succeeded because historically it was easier to install and faster than any libre RDBMS, not because it wasnߣt crappy.

          • I am not arguing that...but I think you will actually find people who actually like and prefer MySQL. Such is the way of things.
            • The fundamental reason we chose MySQL was out of the box replication. Now, this was a couple of years ago so other open source RDBMS might have caught up by now but lack of replication did prove to be a major showstopper.

              Sure, for small apps, lack of replication is usually ok and a single DB server works just fine. When you're working on something a little bigger and you find yourself with 30+ DB hosts sitting behind a load balancer, you will be extremely happy with the replication options available to yo
              • I don't think any of the other major libre RDBMS come with decent and/or out of the box replication.

                Postgres replication is still a 3rd party add on, and it doesn't come with commercial support either, oh and it can be backwards incompatible in undocumented ways between releases.

                Also it corrupts itself unless you vacuum the databases and is a resource hog.

                Despite all that it is still the right choice for some projects, just as mysql is for others.
                --

                @JAPH = qw(Hacker Perl Another Just);
                print reverse @JAPH;
    • Or rather, chances are you're not asking the question you think you are.

      For certain problems it's obviously a good choise (in my experience it seems those problems are pretty rare though).
    • Right because :
      What libre RDBMS has Commerical Support, proven and reliable replication and backup and a decent GUI?
      is obviously such a wrong question.

      I work with MySQL and Postgres almost exclusively and have to say that 9/10 times I would choose the former over the latter - especially if I'm clustering.

      For all the talk about MySQL corrupting data it remains anecdotal and hasn't really been seen in production, fail to vacuum your postgres however and that's your data corrupted or lost.
      --

      @JAPH = qw(Hacker Perl Another Just);
      print reverse @JAPH;

      • That fits my experience as well. (Also, as a matter of personal preference, I don't care for the PostgreSQL CLI.)

      • For all the talk about MySQL corrupting data it remains anecdotal and hasn't really been seen in production...

        Did you mean that you haven't seen it in your production environment? I get hit with this all the time and it's terribly frustrating to get pulled away from real work only to find yet another bit of code I have to patch because the MySQL developers didn't think data integrity was important. I know I'm not the only person with this problem.

  • I honestly don't follow your explanation.

    • That's because I've been complaining in this blog about similar issues long enough that I kind of take it for granted that the background is known. That's a bad habit and I thank you for bringing it to my attention.

      I started to answer your question but the answer went on long enough that I felt a separate journal entry was appropriate [perl.org].

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.