Re: Postgre vs MySQL

Hi everyone,
I know this might be a stupid question. I'm migrating a part of our MS SQL
database to PostgreSQL. I first also evaluated MySQL, but without subselect
support it was unusable for our company (we have many, many queries making
use of subqueries, eventhough it's maybe not optimized for speed but more
practical to read for several reasons).

Besides this, what's the answer to the question "Which one is better?
PostgreSQL or MySQL?"? I'm using SuSE Linux 8 and I need a high-performance
database which will contain about 2-3 GB of data (it's a mailserver logging
we have to keep for legal reasons). Is PostgreSQL the right choice? I
certainly hope it is, it hasn't disappointed me during the last few days,
but as I said, I'm rather new to Unix databases.

Thanks for your advice

-Manuel

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

On Fri, 5 Jul 2002, Manuel W. wrote:

> PostgreSQL or MySQL?"? I'm using SuSE Linux 8 and I need a
> high-performance database which will contain about 2-3 GB of data
> (it's a mailserver logging we have to keep for legal reasons).

The question you should always ask is what tool is right for the job.
Postgres, due to its design, is great for databases that need lots of
integrity checks, foreign keys, and so on. Mysql is in many ways, a
glorified file-storage mechanism with a SQL front-end. Its simplicity
gives it many advantages when you don't need all the features of
postgres.

But the real question is why a database at all? Mailservers have their
own logging systems usually, so why not just save that? A database
doesn't seem the best place to save logs relating to legal requirements
when those are generally around the 2-7 year range.

Personally, I'd start by using flat files. Then, if lots of people need
to query them for some odd reason, go to mysql. Then if you really need
foreign keys, triggers, stored procedures, and so on, go to postgres.
No reason to jump straight to the endgame. It's akin to using an ICBM
to swat a fly. ^_^

--
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
| Shaun M. Thomas INN Database Administrator |
| Phone: (309) 743-0812 Fax : (309) 743-0830 |
| Email: sthomas(at)townnews(dot)com AIM : trifthen |
| Web : www.townnews.com |
| |
| "Most of our lives are about proving something, either to |
| ourselves or to someone else." |
| -- Anonymous |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+

On Fri, 5 Jul 2002, Shaun Thomas wrote:

> Mysql is in many ways, a
> glorified file-storage mechanism with a SQL front-end. Its simplicity
> gives it many advantages when you don't need all the features of
> postgres.

Advantages such as what? It does have less row overhead, which is good
if you've got very small rows, and that also makes importing data
faster. It also has much better access control, though postgres' will
impove with the next release this fall. But all in all, I'd say that
there's not much that really makes MySQL better.

> But the real question is why a database at all? Mailservers have their
> own logging systems usually, so why not just save that? A database
> doesn't seem the best place to save logs relating to legal requirements
> when those are generally around the 2-7 year range.

Yeah, I'd tend to go for flat files here, too.

> Personally, I'd start by using flat files. Then, if lots of people need
> to query them for some odd reason, go to mysql.

I think that there's no reason, in this case to chose MySQL over postgres.

> No reason to jump straight to the endgame. It's akin to using an ICBM
> to swat a fly. ^_^

In this case, the ICBM is just as easy to use as the fly-swatter,
and does just the same job, but leaves you the ICBM capability in
reserve should you need it. :-)

cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC