October 14th, 2001, 09:06 AM
PostgreSQL over MySQL
We have been running MySQL for about 2 years and have been thinking about trying out Postgresql. I'm very new to Postgresql and hoping for some input on how compatible our current perl scripts which are working with MySQL would be with Postgresql or do we need to re-design all our databases and re-code our scripts. What are, if any, main advantages of Postgres over MySQL.
We're running on a Redhat/Linux 6.2 server.
Also where can I find some indepth docs on Postgres? I've been to their site, but most of the docs are somewhat vague.
October 16th, 2001, 09:22 PM
I believe if you're going to be doing a lot of work with an RDBMS you should go with PostgreSQL. I have found it easier to set up and use than MySQL, and I find that it follows the SQL standard. More importantly PostgreSQL is fully ACID compliant, whereas MySQL is not (though it may be now, I don't know -- for more info on what ACID means, see http://www.arsdigita.com/asj/aolserver/introduction-2, and page down to where he talks about Oracle).
PostgreSQL is very easy to manage and use, and I believe it is an enterprise-capable database, whereas I would not consider MySQL to be so. I'd consider PostgreSQL to be the open source equivalent to Oracle, only better because it doesn't require a full time admin just to keep it working, and it seems to be as fast. And of course, it's cheaper. :)
Here are a few links to get you started:
October 17th, 2001, 01:23 PM
Thanks for the info. It well really help.
Been working with MySQL so long,... now gotta find time to learn a new RDBMS all over again.
The only thing I don't like is the way Postgresql assigns users privileges to the database/tables... alot different then MySQL.
Again, appreciate the feedback,
October 17th, 2001, 07:41 PM
No problem. I don't use the grant tables and permissions...I'm using AOLserver with the nspostgres module to connect to the db, and both run as the same user. The AOLserver process validates the user, and the data objects in the database store the info on who can do what with what object (an object in this case is simply a row of data). We're basically creating an object data model on top of a SQL RDBMS.