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.
  • by ziggy (25) on 2003.03.24 12:33 (#18256) Journal
    For the record, I've been developing database-backed apps for over a decade. I've used a variety of commercial RDBMSes, including some embedded databases, as well as low-grade hacks: text files, CSV, DBM and the like.

    One feature I cannot seem to live without is the ability to do complex subselects and joins. It's a thorn in my side when I can't do this with MySQL, but somehow I manage to not need it when I'm hacking with MySQL. Another favorite feature of mine is the ability to create and query against views. In most cases, views are a nice-to-have feature that can be routed around with sufficiently tricky SELECT statements.

    I've also never written a stored procedure in PL/SQL or any other language, nor have I ever needed a trigger (except for the odd hack to enumerate records). Again, I've seemed to manage somehow.

    I'll grant you that a lot of people need these features in their apps, but MySQL sheer existance and popularity never ceases to amaze me with what people can do with basic, rudimentary features. If shops like Yahoo! can use MySQL as heavily as they do, it can't suck that much. Sure, they could come up with a BerkeleyDB-based solution, but it's much more productive for them to use a real RDBMS with SELECTs, ORDER BY and the ability to index on demand. That would make about as much sense as throwing out their Perl, PHP, Java, etc. programs to rewrite their entire infrastructure in FORTH.

    MySQL is slowly gaining one feature at a time from PostgreSQL. Sure, it has transactions now, but how mature is the implementation?
    That's FUD and you know it. Either their ACID compliance is 100% or it isn't. You cannot have 99 44/100% data integrity in a relational database. (Both offer row locking, although some of MySQL's table types are explicitly less granular.)
    And it has subselects, but those were introduced in Pg more than a couple of years ago, and have had a lot of time to get more and more optimized.
    More FUD. Either they work or they don't.
    So, my advice is, if you need a real database, you can't pick MySQL at this point. And even if you think you can get by with MySQL, who is to say that you won't need more features later?
    And my point remains that most people don't choose a database based on a lengthy feature list. There are always other factors. MySQL has done a great deal to give voice to some of the them: size of the user community, number of addon utilities, ease of use, ease of administration, quantity of worthwhile documentation, etc.
    As for support, RedHat's database is PostgreSQL, so you can buy commercial support easily if you're already in the RedHat camp.
    RedHat isn't really pushing RHDB anymore. Word on the street is that this was a bargaining chip against Oracle to force them to more actively support Oracle on RHLinux. On paper, it looks like a nice option. In reality, I don't think its as nice as the marketing department would have you believe, nor is it an option if you're not a RHLinux user.
    • Both offer row locking

      Actually, PostgreSQL implements a solution called "Multi Version Concurrency Control" or MVCC, which is billed as "better than row-level locking." This is even more advanced that what Oracle uses, although I would not expect that gap to stay open long.

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
      • MVCC is exactly the same as what Oracle uses.
        • Um, not according to my O'Reilly Oracle 8, 8i, and 9 Essentials book which describes row locking in great detail. Google for some combination of PostgreSQL, better than row-level locking, and MVCC for their claims that they have it and Oracle doesn't.

          Poking around oracle.com with google, I see this [oracle.com], which suggests MVCC for queries, but I believe PostgreSQL uses it for all aspects of a transaction, including DML as well. MVCC replaces row-level locking, so I wouldn't expect to see references to row-level

          --
          J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
      • MySQL also implements multiversioned database [innodb.com].
        --

        Ilya Martynov (http://martynov.org/ [martynov.org])