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

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

X is better than Y 6 Comments More | Login | Reply /

 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 have these features! Well, okay, but they only just added them! Well, okay, but it doesn't have all! Well, okay, but they're not stable yet! Well, okay, but they haven't had them for years and years! Well, okay, but it's still a toy!"

              It's really amazing -- you can win cool prizes by playing Bad and Increasingly Untrue Things People Say About MySQL Bingo.

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