That's not much of an argument, is it? Sure, you don't pay license fees for Perl nor for MySQL. But you don't pay license fees for Java, C or Python either. Nor for Postgres. Note, I am not advocating you should use any of those. But "I have used X and Y, and I don't want to use Z" doesn't make X and Y the cheapest solutions. Development, maintenance, modifications all take time - and people working on them will want to get paid for it. However, I wasn't argueing price.

I don't think the client can afford a dedicated server at all. That basically leaves an ISP.

Interesting. You don't even know whether the client can afford a dedicated server, yet you conclude using an ISP is the best option? Sorry to say, but that doesn't sound like you've done much of an investigation. However, there's nothing wrong with using an ISP. But it is wrong to tell your client his best option is to use an ISP that doesn't give you much freedom. If you can't even install modules of your choice, your client is much better off with an ISP that does give your client at least that.

I don't think that the posting of a job on a jobsite is the kind of data that warrants using Oracle etc.

Did you ask your client how important they think the data is? Can they afford losing the respect of their customers (the people using the website)? If your client doesn't care about losing the data (resumes, etc), then why are they collecting it in the first place? Is your client planning to make money (directly, or indirectly) with said data?

I would appreciate it if you can give me concrete reasons why Perl and MySQL would not be a good solution, even if it is hosted on an ISP.

I didn't say I objected to using Perl. There might be reasons not to use Perl, but your article didn't say (if the application is going to be developed and maintained by a team of 40 Java jocks with no Perl experience, Perl is likely not to be a good choice). I did, however, post a link to a page giving a multitude of reasons not to use MySQL. If those aren't concrete, what reasons are?

-- Abigail

Actually, just posting the data--that is, putting it into a simple database for read-only queries--isn't a bad use for MySQL, from what little I know about it.

But keeping the data that's uploaded is a whole 'nother story. I read that MySQL has been improved in the year since the original article was written, but I wouldn't even think about using it as was for anything critical.

Update: I spent a little time going through the MySQL manual, and I'm now convinced I wouldn't use it for most purposes. What improvements have been made are minor, from my point of view.

The idea of having some tables in a large database optimized for speed in read-only access is kind of neat, but I think it'd make more sense to use a proper RDBMS and export such tables into something like MySQL for that access.

adamsj

They laughed at Joan of Arc, but she went right ahead and built it. --Gracie Allen

The client is a startup company, so it doesn't have a huge bunch of capital to spend on the site. They also consider advertising to be the one thing to spend most of their money on, not the development of the site. Obviously the site is important to them, or they wont spend such a lot of their startup capital on it. The site will basically be their means of income, so it is a crucial part of the company.

Company decided to be cheap on basic mean of income, and instead to spent most of money on marketing? Looks like "get-rich-quick" scheme to me.

If you decide to go for it, at least get agreement to be paid step-by-step. Protect yourself before possibitity that company will go belly up before you got paid.

For me is very hard to imagine a situation where I can use database without solid atomic transactions and rollback. If MySQL cannot support rollback, I will avoid using it for important production data even if paid to do so. And in no case for payment & Credit Card processing. Are you looking for troubles?

You are taking rather big risk, I hope at least your award is worth it. :)

pmas

I should repeat that for emphasis: I've never had a problem. No lost data. No mysterious crashes. Nothing except good performance and reliability. (Performance was about 9 times faster than Oracle by my benchmarks in the application I was running at the time it was ported to Oracle.)

The link that questioned MySQL as an adequate database and questioned whether it was just waiting to fall apart at the seams because it doesn't have atomicity or rollback obviously was put together by someone totally unfamiliar with its use in a production environment and who seems like they were more concerned with communicating their knowledge of esoteric (but good to know!) database concepts than reality.

Of course, it doesn't have as many features as Oracle or other large commercial databases, but it sounds like for your needs, it's just what you need.

I should repeat that for emphasis: I've never had a problem. No lost data. No mysterious crashes. Nothing except good performance and reliability.

And I know people who become 100 years old while smoking 2 packs of cigarettes and a handful of cigars every day. Never coughed in their lives. But that doesn't mean I'm convinced smoking isn't bad for your health.

I have been a full-time Sybase DBA. And I have adminned a MySQL server too. I've seen things happening to boxes running my Sybase servers that would corrupt a MySQL database under heavy load, while the Sybase databases recovered flawlessly (that of course doesn't mean you'll never lose or get corrupted data with Sybase) I have turned the key of the wrong box, shutting down a 4 engine database with over 1000 simultanous connections. I've seen brown outs, causing 20 disks to think it's time to spin down while the box itself thinks there's no problem to worry about. I have typoed, deleting vital information in the master database, which I could simply roll back. Can MySQL make a *consistent* dump of a running database? Without referential intrigity or triggers? Can MySQL make incremental dumps? Say, every 15 minutes on a multi-gigabyte server?

The link that questioned MySQL as an adequate database and questioned whether it was just waiting to fall apart at the seams because it doesn't have atomicity or rollback obviously was put together by someone totally unfamiliar with its use in a production environment and who seems like they were more concerned with communicating their knowledge of esoteric (but good to know!) database concepts than reality.

Saying that Philip Greenspun is unfamiliar with the reality of using database in a production environment is barely less absurd than saying Larry Wall is unfamiliar with designing computer languages.

-- Abigail

I've used MySQL for websites that get millions of page views involving up to hundreds of millions of queries per month without ever having a problem.

Page views? Great. MySQL is great for read-only databases that don't need any transactional capabilities. As long as you realize that its just a file system with a (very basic) SQL interface, then fine.

I know of one company doing hight volume credit card transactions that has been using MySQL, and is moving to Oracle because MySQL can't handle the load without corrupting data which is another issue warned about in the article.

And I hope you never have to back up that database/filesystem while the data is changing :)

As for other free options, theres PostgreSQL

Rollback and atomicity are NOT esoteric concepts.

--