Re: [ILUG] Drop in replacement for Ingres Database?

From: kevin lyda (kevin+dated+1032633391.b96a44 at domain ie.suberic.net)
Date: Mon 16 Sep 2002 - 19:36:46 IST


On Mon, Sep 16, 2002 at 06:41:13PM +0100, Conor Daly wrote:
> That's essentially what we are doing with our DB. There are a few
> "triggers" that call a switchboard application which, in turn, starts up
> other (external) procedures.

if you use triggers, you'll want to use postgres. if you can get around
them, you can use either.

and i hate saying this, i really hate saying it, but it's a datapoint
so... however i'm going to spend the rest of this evening rapping on
everything wooden in my house.

we have one db that's been up since 1999. not as in uptime, but the db's
been in existence since then and heavily used. it's survived a number of
db upgrades - both the mysql version and from one table type to the other.
we have another db that's been in use since 2000. it's a key db and
must be up 24/7. there are a number of other mysql db's in-house as
well, all fine. in fact i can think of four mysql db's at work (two
installed in 1999, two in 2000) and they have run 24/7 for their entire
life with pretty much no maintenence. in fact i'd bet a fair number
of people at work haven't a clue they exist (even though a fair number
of transactions go through them). there's a master db for those 4;
and that's been up since 1999, again with no maintenence to speak of.

i'd guess conservatively that these db's (in fact just two of them alone)
capture and process over ¤2,500,000 in sales every week. i don't really
pay much attention, but i'm guessing that would safely come under what
actually goes through all six of them.

so there you go. you can surf the net and get lots of benchmark numbers,
but there's a number your managers might appreciate. i honestly would
feel more comfortable with mysql based on my experience. but with the
appropriate (aka equivilant) knowledge, i'd bet postgres would be fine.
both postgres and mysql come across as more polished applications then
the closed source db's i've seen. get the docs for mysql or postgres.
read them over. play with them; try some of your sql on them. check out
the c/shell/perl api's that you'd need to use. if you can, try porting
a small, testable bit of your application and see how it goes.

kevin

-- 
kevin at domain suberic.net     that a believer is happier than a skeptic is no more to
fork()'ed on 37058400    the point than the fact that a drunken man is happier
meatspace place: home       than a sober one. the happiness of credulity is a
http://ie.suberic.net/~kevin   cheap & dangerous quality -- g.b. shaw


This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:18:53 GMT