in reply to Which DB for Windows, and how to design music DB (was: databases)

It seems like your most important question is "what database am I going to use?". Which isn't really a Perl question. It's not an easy question to answer. Don't listen to people who just say "oh, just use mysql", they clearly don't know much about databases - anyone who suggests a database without knowing anything about the data being stored is not someone you should listen to.

I'm not going to suggest any database, as you have given way too little information. You have to ask yourself a couple of questions. How much data do you have? How important is your data? What kind of queries are you going to perform? How important is your data? Will there be many updates? How important is your data? Is it mostly a transaction system (many inserts/updates), or a decision system (big, complicated queries)? How important is your data? How fast does it have to be? How important is your data?

Note that I keep hammering on one particular question. If your data is really important to you, you do need a database that will garantee you integerity and consistency of your data, atomic actions, etc, even if disks crash or if someone pulls the plug. If your data isn't important, why even bother? Oh, and one often suggested database, which I won't mention but it has 5 letters and is often written in mixed case, doesn't offer you those vital features. "Free and fast" doesn't equal "good".

As for Perl, the most common interface to a database is with DBI and a driver specific to the choosen database. DBI gives you a bit of a primitive interface, as it's aimed at the lowest common denominator. The upside is that it has drivers for (almost?) all of the popular database engines. O'Reilly also has a book about it.

Abigail

Replies are listed 'Best First'.
Re: Re: databases
by legLess (Hermit) on Jun 03, 2002 at 19:09 UTC
    What Abigail-II is trying to say, very circumspectly, is that MySQL is often thought not to be a full RDBMS (relational database management system). MySQL has intentionally left out some features that some people believe are (a) useful, or (b) necessary for a product to be a true RDBMS. Among (a) are subselects, stored procedures and triggers. Chief among (b) are transactions.

    The most important criticism of MySQL is that it doesn't support transactions, although this is no longer strictly true. The current alpha has good transaction support (although the code is ... well ... alpha); version 3.23 and up support transactions on some table types.

    Why should you care about transactions? Say that you're a bank, and each time a customer makes a purchase you (1) debit their account and (2) credit the merchant account. What if the power goes out (work with me here) in between (1) and (2)? Sounds like a nightmare to code, eh? Transactions are a way of letting the database keep track of this by wrapping up a number of operations into one transaction which either totally suceeds or totally fails (in the case of failure the already-executed parts are "rolled back").

    MySQL's response is that they delayed implementing transactions because most people don't need them. This is true, and often overlooked by serious database people. Wittgenstein once said that what most philosophers think of as rigorous proof is like buying two copies of the morning paper and comparing them character-by-character before you believe that either is genuine. In short, don't let MySQL's lack of transactions scare you away. If your data's so important that you need transactions, you should be hiring a database expert anyway.

    MySQL is reputed to run better than PostgreSQL under Windows.

    Here's a pretty decent comparison of the two (note that it's by the MySQL team, but is pretty honest). Here's some good PostgreSQL and RDBMS documentation. Some of it is Linux-specific; most is agnostic. Here's also a good article on PHPBuilder comparing MySQL and PostreSQL. It's light on the PHP but very specific on the databases (in particular, speed).

    Finally, the O'Rielly Perl DBI book is very good, but DBI isn't that complicated. I'd suggest getting a good SQL book instead and reading the man pages and online tutorials for DBI.
    --
    man with no legs, inc.
[reply]
      Transactions give you many things. Isolation, duration, etc. But there is more missing from MySQL. Safe on-line backups. (No, just backing up the filesystem with the tables will not do if you want to keep data consistent). Triggers. Integrety checks. Nested queries.

      I strongly suggest reading http://openacs.org/philosophy/why-not-mysql.html. Only use MySQL if you truly understand the dangers.

      Finally, the O'Rielly Perl DBI book is very good, but DBI isn't that complicated.

      Most certainly. However, writing good SQL queries can be an art in itself. Many queries are simple, but when they get more complicated it's easy to write something that runs for 24 hours, while it could have been done in 5 minutes.

      Abigail, DBA in several former lives.

[reply]
      It is necessary to point out, 3 1/2 years later, that MySQL 5.0 (which has just been released) has every single feature avaible in Oracle 10g, and then some. This includes the basics such as transactions, subselects, triggers, and stored procedures. It also includes the neato-keen features, such as clustering, replication, and multiple-indices-per-table-per-query.

      MySQL has certainly grown up.

      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]

In Section Seekers of Perl Wisdom