Is mysql eventually better suited for the use with perl ?

Your decision of what is the appropriate database to use should not depend on the language you use, but on your data. How important is the data to you? How volatile is it? What kind of queries are you going to perform? How often? How important is performance? How much data are you going to store?

Abigail

Listen to Abigail-II

Don't think of it a what is right for Perl but what is right for you. Perl can be used to touch practically any database, the list of compatible DBI modules keeps growing. We seem to adopt that which we first come in contact with. Which you seem to have done, but it doesn't hurt to look around. Here is a link to MySQL's db comparison page.
Some other things to consider:


How stable is it?
How portable is it?
How secure it is?
How easy is it to administer?
What kind of support is available and does it have a cost?
How much does the db cost?(for the budget minded)
How mature is the DBD module for the db you want? If you are using DBI.
What third party apps are available for it?

Cheers
Gyro

If I can ask a further question here... I'm moving towards Pg myself (from MySQL) and one "gotcha" that I've come across is getting the insertid from the previously-inserted record. In MySQL, it was something like:

$sth_insert->execute( $chain, 'chain' );
push @relationship_ids, $dbh->{'mysql_insertid'};
[download]

In Postgres, I have to do something like this (b/c I don't know any better {yet}):

$sth_insert->execute( $chain, 'chain' );
push @relationship_ids, ( $dbh->selectrow_array( 'SELECT last_value FR
+OM entities_id_seq' ) );
[download]

Thanks!

Jason

for simple persistence DBM will often be enought (or DBM::Deep which is very perlish ) , if you plan complicate data structure you may need a SQL interface involving DBI. which you can plug on different DataBase.

You can access them all using the same interface DBI. As all others have said, ask not what you can do for your database, but what your database can do for you.

PS, i use postgres..

Another vote for Postgres. Historically, Postgres has been a little more stable, robust, and feature-rich than MySQL, though the gap is closing rapidly. It's also a higher performance database, at the cost of some additional complexity and resources.

I think my preference has much more to do with the preference for the elephant mascot and my anti-microsoftian dislike of "My" in front of program names :)

Still, tons of Linux apps are written exclusively to use MySQL. I'd like to see them written with tools such as DBI, ODBC (pain!), etc, more often so that they are portable and users can choose what DB they want to use.

If it's for learning purposes though, I'd definitely go the Postgres route.

Sidenote: you said you were using the Cygwin version. Looks like a Win32 port is preceeding here: http://momjian.postgresql.org/main/writings/pgsql/project/win32.html. Until then, perhaps (just perhaps) MySQL might be better on Windows. Of course, anything other than MS SQL Server is a good thing :) Also, I believe Informix (disclaimer: untested & I have no opinion) is also free for Win32.

Still, tons of Linux apps are written exclusively to use MySQL. I'd like to see them written with tools such as DBI, ODBC (pain!), etc, more often so that they are portable and users can choose what DB they want to use.

Don't get me wrong: I, too, would love to see more apps that are written exclusively for MySQL to be database-agnostic, but the problem is not in the lack of using DBI. The problem is that all of the major databases I can think of (Oracle, MySQL, Postrgess, Sybase, MS-SQL) use different dialects of SQL. That is, you have to write out a different SQL statement for one DB than the other to do exactly the same thing.

Granted, using DBI, or whatever the closest analog is in your language of choice, will make such porting issues easier, but there's no getting around the fact that, for example, join syntax is different between MySQL and Oracle. If you want your app to be usable on both DBs, simply coding it with DBI doesn't make it happen. You need to EITHER make all of your SQL so ridiculously simple that you might as well use a flat DB instead of an RDBMS, OR to make separate DB access sub-modules in your app for the databases you plan to support.

------------
:Wq
Not an editor command: Wq
[download]

Oracle server is going to cost quite a bit depending on the version, number of CPUs etc. It does however meet the requirement of being right for Perl. It just might not be so right for your bank balance!

And depending on the version you buy. They dropped their prices on certain versions to compete with MS recently. 5000 for one node, one cpu ain't that bad.

Play that funky music white boy..

MS SQL server and the cut down version MSDE would also be on the list of database engines to try. Unfortunately the only DBI driver that I can find that works is the ODBC one. This limits a number of the features that you should be able to use with SQL server. Other than that, I find that SQL server works pretty well.

A lot of people have offered good reply's but I'll offer my own.

I personally use mySQL and I love it. It meets my needs and it's free. (for personal use/open source software) PostgreSQL is another good database. Either way you are mostly using SQL commands which are pretty much interchangable. The only other database I would suggest you look at would be oracle. While not free I think they have a stripped down version for free.

For learning, either mySQL or PostgreSQL are both good options. Pick on and go from there. Perl is very good at accessing databases. (Oracle, mySQL, PostgreSQL and more)