Re: MySQL vs. Postgres
>
> > postgres is using record-level locking, what does mysql do, is it
> > locking the whole table ? what are rollbacks? what other advantages
are
> AFAIK mysql locks whole table,
> rollback is term used with transaction - thing is, you put some sql
> statements inside transaction, and one of them fail, you rollback all
your
> changes so your database is in consistent state.
> This is very important thing especially in networked apps (and that's
what
> you need sql server for, don't you?).
> I'm probably a little bit biassed against mysql, since in their docs
they
> talk about transactions like their useless and that's why they haven't
> implement them ( and not because they don't know how ;).
> And according to my knowledge transactions are one of the fundaments
> of database programming.
>
I disagree with Eyck on this. I am a database programmer, have been
since dBase II back in the early '80s. It all depends upon the
application. Transactions are very, very useful under some
circumstances, but if you can do without them, you can speed your
database engine up a lot. Same thing with Foreign Keys, which MySQL
does not support. If your application is going to be a large database
with multiple tables that will need to be updated simultaneously, then
Eyck is 100% correct, you need a database that supports transactions.
However, most of the web based stuff I write does not require this. I
am generally updating only one table at a time. In this case, I go
MySQL to decrease my resource requirements.
>
> > there in using postgres instead of mysql ?
> It's only my personal opinion postgres is more secure due to easier
> administration and ability to define remote access permissions
> easily and precisely.
MySQL has a weird way of setting permissions, but once you figure it
out your permissions are granular down to the user/table/action, which
is what I get out of the "Big O" also.
Point is (and I don't want to turn this into a religious argument),
choose one. If you choose MySQL and find that it doesn't do what you
want, change a few lines in your scripts (or, maybe an access module
used by all your scripts) and turn on postgres. If you choose postgres
and find it is too slow, and have optimized your queries and tables, do
the same thing and go to MySQL. Your scripts should remain essentially
the same, especially if you keep all db access scripts in one location.
<-----------snip------------>
Rod
Reply to: