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.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.