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 ]

gav (2710)

gav
  (email not shown publicly)
http://www.estey.com/
AOL IM: flufflegavin (Add Buddy, Send Message)

Hacker in NYC.

Journal of gav (2710)

Friday February 27, 2004
09:30 PM

X is better than Y

[ #17666 ]

MySQL is so late-90s. Everything that MySQL used to be good at has now been beaten: DBD::SQLite for the low-end, and DBD::Pg (to PostgreSQL) for the high end. Please don't waste your neurons learning about MySQL unless you are supporting legacy apps or legacy thinkers.

-- Comment by Randal

This reminded me of something Mike Hillyer wrote:

First of all I understand that the tool/language/OS you use is the cat's meow, and I am really happy for you that you found it. I also assume that you chose your new favorite tool/language/OS (lets call it TLO from now on) after carefully considering the costs, benefits, and other pertinent factors involved in a decision of such magnitude.
Now please afford me the same understanding and assumption.

[...]

I understand that you think MySQL is garbage. If you tell me so I will first assume you are a Postgres user. Listen up guys, get over the popularity contest. Every time Postgres or MySQL is mentioned on Slashdot it turns into a MySQL bash-fest. Oddly the MySQL camp never gets into a big flame-fest on Postgres, and we don't troll Postgres users like they do for things like Jeremy Zawodny's blog.

-- Stop Saving Me From My Tools! (via Jeremy )

I was thinking about what Randal said, and it's very easy to swap the tools around to get to somebody else's point of view:

Perl is so late-90s. Everything that Perl used to be good at has now been beaten: PHP for the low-end, and Java for the high end. Please don't waste your neurons learning about Perl unless you are supporting legacy apps or legacy thinkers.

I'm a happy Perl and MySQL user, both tools have advantages and disadvantages compared to other tools. I'm sure a different person would use a different toolset to solve the problems I solve with them. I'm just happy that we have these choices.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • For a long time, the only game in town was Matt Wright, and Matt's scripts got a lot of airplay and mindspace. But the NMS project rewrote them, and now there's no reason to use Matt's scripts now that NMS is out. But that doesn't stop people from continuing to suggest Matt's stuff, only because they don't know any better.

    MySQL is there mostly from inertia now. Other than legacy compatibility, there's really no reason to use it. So for new starts, I'm trying to help set the record straight, in the NMS

    --
    • Randal L. Schwartz
    • Stonehenge
    • I still don't understand your issue with MySQL. It's not like it's a big security risk which was the reason to avoid Matt's scripts. What is wrong with MySQL?
      • The main point in the nms vs Matt Wright thing was not the security issues (most of those have been cleaned up in even Matt's code), it was that people who knew Perl knew that Matt's programs weren't good Perl.

        It's the same with MySQL vs PostgreSQL. People who know databases know that MySQL isn't a good database. Sure it does the job if your requirements are simple. It probably looks great if you're coming from something like MS Access, but if you're used to using a "real" relational database system like D
        • * Transactions

          We've had transactions since 3.23.34a (with InnoDB)

          * Sub-selects
          * Stored procedures

          Maybe what I generally do with MySQL isn't that complicated but I've managed to survive without both. Sub-selects are working in 4.1 and stored procedures in 5.0.

          * Referential integrity

          FOREIGN KEY added in 3.23.43b

          There is a lot of interesting things on the horizon for MySQL users, especially due to the merging with SAP DB. You can use MaxDB which has a lot of these features working now.

          • * Transactions

            We've had transactions since 3.23.34a (with InnoDB)

            But, as I understand it, you lose a lot of the speed if you use them.

            * Sub-selects
            * Stored procedures

            Maybe what I generally do with MySQL isn't that complicated but I've managed to survive without both. Sub-selects are working in 4.1 and stored procedures in 5.0.

            Stored procedures are essential (IMO) if you will have more than one client application connecting to the database. Otherwise you'll have the same business logic implemente

            • Sounds like it's getting there, but PostgreSQL is already there - and has been for some time. That's my main point.

              That's fair, but Randal's point is that SQLite and PostgreSQL have superseded MySQL at the things MySQL is good at. If I were to apply your rule above to that situation, I could fairly claim that SQLite and PostgreSQL are getting there but MySQL is already there and has been for some time.

              Is that a facile analysis? Absolutely.

              Still, the whole debate seems to be that "MySQL doesn't hav

    • MySQL is there mostly from inertia now.

      While I think this statement is a hundred percent correct... It is only half the story.

      I have never used PostgreSQL, for one simple reason.

      I have not needed it.

      Inertial? Sure.

      But, until the benefits justify the cost, it doesn't make sense to spend my time replacing something that "just works" for me.

      Sometimes "good enough" really is...
    • That's a terrible analogy. It's no secret that Matt's scripts are poorly written (is MySQL poorly written?), with no support (does MySQL have support?), numerous security flaws (is MySQL insecure?), and no active development (has MySQL stopped progressing?).

      I'll tell you reasons to use it over PostgreSQL: better support on Windows, nicer client interface, better documentation, from the project itself as well as from third parties, and a much saner upgrade scheme. I also hear that its replication support

      • Neither of the options Randal presented would be satisfactory for Slashdot: SQLite is too lite, and PostgreSQL is too slow. We have transactions when we need them (which is seldom), we don't need or want stored procedures. Lack of subselects sucks, but you take the good with the bad. So, whatever.
  • search.cpan uses MySQL. It's never been a performance star but, then again, neither has Perl. I also use MySQL for a lot of other stuff. The only gripe I have with it that I've begged Monty for rather shamelessly is the lack of cascading deletes.

    And, Perl is very late 90s. Ruby, not PHP, is the future. :)