Sagi Bashari wrote:
I've been working with MySQL for few (4?) years now, partly powering few big israeli ecommerce websites. I only missed this feature once - when we needed to do on the fly currency conversion. However, we solved it by writing a small MySQL module in C.
Leaving the controversial license aside (more precisely, the controversial license's interpretation by MySQL AB), it was my understanding that MySQL was designed with speed, rather than data integrity, in mind. As such, the most lacking feature to me is a totally guarantee that no matter what abuse the database, database server, and database server machine go through, my data is in a consistent state.
While I understand that this usually comes into play in the form of features such as transactions etc., I don't understand how such features can be retrofitted into a database. Maybe you can help shed some light on that point for me.
If I had to write a new application day, from scratch, I would probably consider postgresql again. However, your statement regarding mysql not being suitable for "anything more than one table website" is very untrue.
Again, trying hard not to troll. Can you explain why you would consider PG for new applications if MySQL has what a db user would require?
MySQL still has its advantages over postgresql (such as better documentation and much larger userbase, but also technical features like built in replication and fulltext search).
Moreover, MySQL will get real i18n support and subqueries support over the next few months (v4.1),
When you say "real i18n support", what do you mean? What does MySQL not support at the moment?
and support for features like real stored procedures and cursors over the next year (v5)
The thing is that I'm not comfortable referring to not-yet existing features. PostgreSQL is going to have some sort of native Windows support in the upcoming version. It's already committed into CVS. Still, this is not something you may necessarily want to run a production server on. They currently focus on reliability, rather than speed, which may result in it being faster and more efficient to run it in cygwin or in colinux. How much will MySQL stored procedures, or for that matter, transactions, suffer from the same symptoms?
Sagi
To me (and please correct me if I'm wrong) it seems there is little doubt that PostgreSQL is FAR more feature complete than MySQL. It has had foreign keys, transactions and stored procedures for ages. Same goes for Unicode support and cursors (readonly, I'm afraid). State of the art (i.e. - still in development) in Postgresql currently talks about nested transactions, checkpoints, and PITR (Point In Time Recovery), which are likely to still be YEARS away in MySQL (ignorance disclaimer from above applied). It has a license that is suited, without any controversy, to both free and commercial projects. With such considerations, one has to ask (and I do here), what are the reasons for choosing MySQL? As far as I can see, new projects should mostly consider Postgresql vs. Firebird.
While we are on the subject, can anyone comment as to where Firebird stands in these respects? I understand it's fairly mature, but I don't know just how much.
Shachar
-- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
