1. Scalability/Performance - 9i can use clusters better than any of the others
2. Scalability/Number of Users - every version from 7.0 up can use MTS (and more in newer versions) for servicing extreme numbers of users (10K's)
3. Reliability - 9i (or even 8i) almost completely transparent (ie no need to reconnect) failover
4. Hardware independence - everything from a Win95 (or if you really know what you're doing ... DOS) to Mainframes via virtaully every flavour of *nix can support an Oracle database
5. Features - stored procs in PL/SQL and Java, pre-compiled SQL (aka cached queries) and PL/SQL (in 9i), Views, snapshots, full text indexing, web based administration, triggers (on startup, login and shutdown not just insert/update/delete), full audit facilities, security (built in encryption for starters)
6. Metalinks/Technet - a *useful* knowledgebase
7. and it ships with Perl, Apache and mod_perl :)

I don't work for Oracle, and the phone support is pretty much summed up as "upgrade!", but with everything from Personal Oracle Lite to Enterprise Edition freely available for download it's very easy to get started.

Just my 2p worth :)

rdfield

Perl has drivers that allow it to connect with MySQL, MSQL, ODBC and many others. You are using DBI and DBD to connect, after that, the type of DB you are using is irrelavent from perl's standpoint.

From here, concentrate on the database for your needs.

Do you need a transactional DB?
Do you need a relational DB?
Do you need speed over functions?
Is price an issue?
What do most of your clients use?
What is the size of the company or job?
Will you DB be heavily used to monetary transactions?
What OS does the DB support?

I have been using MySQL with perl for almost a year. I have also used perl to access ODBC databases and perl does the job well. I think you may be asking the wrong question.

I use MySQL for the following reasons:

-It is free for me and cheap for my clients.
-It is easy to install and easy to manage.
-It works on many platforms, but works very well on linux.
-It is very fast.

Oracle is great for large companies and has functions for pretty well anything you could want. However, you will pay for this with dollars and speed. It is transactional and fits in very well for e-commerce situations where losing a transaction or corrupting a transaction can prove costly.

MySQL works well for non-transaction based applications and in small to mid sized companies. It is fast and designed to be so. It has few functions compared to ORacle. MySQl is cheap... I could go on, but you need to determine what you need and then create a proposal table to see which DB scores the best

Simon

Why isn't MySQL good for transactions? I've not worked with any databases, but would like to get into it. Only reason would be for e-commerce solutions.
And if MySQL isn't good for transactions, is PostgreSQL?
Just wanting to get a feel of what database system I should start fiddling around with when I get the free time to do so.

Thanks,
Avi

Why isn't MySQL good for transactions?

Transactions have only recently become available in MySQL, so they don't have much of a track record yet. Also, many who are biased against MySQL on the basis of no transactions haven't been keeping up with MySQL (not that there aren't other reasons to favor, say, Postgres.)

This has been an ongoing argument within the engineering staffs at my company for ages... mySQL is fast, but it does not allow for any relational integrity of data within the tables themselves; it also does not support transactions, which I feel is not made up by the improvement in speed. Even simple webpages can eventually end up making multiple updates/inserts/deletes into a database that could potentially cause problems, and would easily be handled by a rollback statement, but with mySQL you have to handle the transaction pieces yourself. PostgreSQL is really a quality free product that performs almost everything that Oracle can do without the pricetag. (not too sure on the scalability as I haven't used it in large deployments) And as a benefit, PostgreSQL allows stored procedures to be written in Perl!

If you need advanced features, I would also recommend PostgreSQL. It's open source, reasonably well-known, and contains a lot of the standard features (stored procedures, views, triggers, etc.) Perl support is very good. However, my experience is that it doesn't necessarily deal well with huge data sets .. for that you probably want Oracle.

One thing to consider if you're a major Perl geek: MySQL either has or is developing a "native" programming language (similar to PL/SQL or PL/PGSQL) but based on Perl. I haven't worked with this myself, so I can't vouch for it, but it's a data point to consider.

Hope this helps.

PostgreSQL has PL/Perl: Perl Procedural Language