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.
 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. :)