use Perl

• once again proving... (Score:2)

  by merlyn (47)

  PostgreSQL is a "real" database... a valid open-source replacement for most of Oracle, while MySQL is merely a step up from using BerkeleyDB for structured storage.

  I can't recommend MySQL for any new installations any more.

  --
  

  • Randal L. Schwartz
  • Stonehenge
  • Re:once again proving... (Score:3, Insightful)

    by ziggy (25) on 2003.03.24 9:36 (#18244) Journal

    PostgreSQL is a "real" database... a valid open-source replacement for most of Oracle, ...

    For the task of migrating an existing commercial RDBMS to an open source one, PostgreSQL is certainly the best choice today. Open Source software is nothing if not dynamic. Most people who write off MySQL do it with old information. MySQL has supported ACID transactions for a while now, and stored procs are being demonstrated live next month at the MySQL User Conference; expect stable, production-grade stored procs in MySQL by the end of the year at the latest.

    For people who are migrating a simple schema (e.g. no triggers, no stored procs), MySQL is certainly an acceptable and a defensible choice.

    ... while MySQL is merely a step up from using BerkeleyDB for structured storage.

    I'm quite surprised to see someone who waves the TMTOWTDI flag and actually teaches the principle of TMTOWTDI to paying students assert that there is only one real choice in the rather vibrant world of open source RDBMS servers. Asserting that PostgreSQL is the only "real" open source database is just spreading FUD and snobbery. The situation changes quickly, and MySQL development versions support stored procs today, so I'd expect to see them in production later this year. Surely the story for triggers is similar.

    It's been a long time since I looked at it, but Firebird [sf.net] certainly deserves a look.

    And lots of people need a simple, fast SQL database engine. In situations with many readers and few writers, MySQL is a perfect solution. (Yes, it's ACID compliant...) If I had a high throughput problem I needed to solve, I'd look at MySQL before PostgreSQL any day of the week.

    Then there are the people who need embedded databases. I'm using SQLite [sqlite.org] for a few projects I'm working on at the moment. After talking to David Axmark last week, I'm seriously considering switching to embedded MySQL. I don't think embedded PostgreSQL is an option. Interbase used to be embeddable; I don't know if Firebird is.

    I can't recommend MySQL for any new installations any more.

    Um, there are plenty of reasons to recommend MySQL for new installations. Not everyone makes decisions on a pure technology basis or even from a my feature list is bigger than your feature list perspective.

    MySQL has a much more vibrant user community around it. Someone who is not a dba and doesn't want to become one is more likely to find an anwer to a MySQL dba question much more quickly than they would a PostgreSQL dba question. Why? Because practically everyone and their pet rock have some experience with MySQL. Plenty of smart people have no hands-on experience with PostgreSQL. Sure these issues aren't difficult to figure out, but a lot of people don't have an answer on the tip of their tongue, nor do they know if a problem has a 30 second fix, or if they need to spend 15 minutes reading the docs to find the 30 second fix.

    And don't even get me started with add-on tools that are available for MySQL but not PostgreSQL. Add all that up, and it makes MySQL a much better fit for a set-it-and-forget-it type installation.

    For someone who is just playing around, MySQL is also a better choice than PostgreSQL, because there are more books, articles and websites aimed at learning database theory centered around MySQL than SQLite, Firebird, PostgreSQL or Joe's SQL. (This is the Torkington Principle applied to databases: «MySQL is a great first database to learn, but PostgreSQL is the last database you ever need»)

    Reply to This

    Parent