I understand that MySQL has recently had some improvements to bring it closer to ACID compliance, but I am still leery of it. MySQL, as I have used it, is as best a file system with SQL, not a database. An excellent explanation of the limitations of MySQL is at Why Not MySQL (and explains what "ACID compliant" means). As for Open Source alternatives to MySQL, you can check out Postgresql or Interbase.

I do not know who recommended MySQL to you or why it was recommended. If the only consideration is performance, I would strongly recommend that you examine this decision more carefully. One thing that many people misunderstand in making technology decisions is that the technology chosen is part of the answer. In order to answer a question properly, you need to get enough information to understand what the question is. With technology choices, we need to identify the problem solved, determine what resources we can apply to these problems and determine how the pros and cons of those resources affect our short and long term goals. Then, and only then, do we begin to have an adequately defined question. Once we have the parameters of the problem and possible solutions clearly defined, then we can begin to decide what technology solutions are an appropriate fit. Here are a few questions off the top of my head regarding that would affect whether or not MySQL is an appropriate solution for your problem:

• What, exactly, is the problem that you need to solve?
• Do you already have technologies in-house that may be applicable (this is important because just throwing another technology at a solution means more technologies to support -- too many technologies is like too many cooks!)
• If you need a database, how many users are likely going to be using the system?
• Will the database be primarily "read only"? (MySQL can be fine for that purpose)
• Do you have the in-house capability to adequately support MySQL? Is there only one person who can support it? What happens if they leave?

The last question is particularly vexing. At work, we primarily use MS SQL Server because that is the database the most of us are familiar with. For some of our projects, we are thinking about switching to Postgres, but there's some resistance due to the lack of in-house knowledge of the product. Unfortunately, that can be a valid complaint if we have acceptable alternative solutions.

Cheers,
Ovid

Vote for paco!

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

• each record in the file contains only one field, e-mail address.
• once you get the file, you are the only person using it.
• you don't expect that format of the file to change anytime soon (like by adding new fields per record).

I work with a file that has 48,193 94-byte records. On our ancient Sun Sparc 10, it takes 3 whole seconds to load the entire file and store it in an array. On our Sun Enterprise 350, it takes less than a second.

In my case, however, I have to break each record into 10 fields, be able to sort across multiple non-contiguous fields, perform merges and complex selects. So I should consider using a database implementation even though the file is used only by me and is never updated (except when I replace the entire file weekly).

"Make everything as simple as possible, but not simpler." -- Albert Einstein

• More complex data than just a single field
• An application that does more than just "get everything in the database".