Shachar Shemesh wrote:

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.


I can only speak from my experience. I never lost any data because of MySQL. MySQL supports transactions for few years now so this is not an issue for me.

One thing, though. Unlike some other DB's, MySQL data types are not totally strict - if you try to insert data of a wrong type it will usually try to convert it instead of throwing an error. This may lead to data loss if your application is poorly written.


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?


Because I may need some features that MySQL lacks, like i18n support and stored procedures. It depends on what the project's demands.


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?


Currently, there is no unicode support in the stable version. If you store such data right now, functions like LENGTH() or fulltext support will not function correctly.

However this will be solved with the release of 4.1 (been in alpha/beta stages for ages now, will hopefully be released before the end of the year).

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?


Those features already exists in the development versions. Once a "stable" version will be released, I believe it will be stable. They've been working on those features for few years now.

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.


I never said anything against PostgreSQL. I can't - My experience with is is very, very limited. My point is only that Michael's statement, that MySQL is not suitable for more than one table website, is totally untrue. The vast majority of small to medium websites will run with MySQL without any problem.

Sagi


================================================================= 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]



Reply via email to