[Asterisk-Users] OT: Best DB

[Chris Travers]

>
> At the risk of sounding like a closed source fan (I'm not) I do think 
> you should
> at least consider Oracle for this job.
> I built a system a few years ago which takes a constant stream of 
> entries from a number (<100)
> of remote systems analizes them and generates reports
> (see http://www.westpoint.ltd.uk/example-reports/reports/index.htm)
>
> We use Oracle for it, and it has been great. Also they have improved 
> the weakest points:
>    1) pricing - It is now _much_ cheaper than it was
>    2) Install - I had a couple of oracle newbies install it in a 
> couple of hours, that was never possible
> in the old days.
>
On the other hand, PostgreSQL is Free and can be installed for light use 
in under an hour from source by a first time user, or far less time than 
that if you use RPM's etc.  Tuning it for heavy load can take a little 
more time, but that is life with a read DB (Oracle is not so different 
in this regard.

> Once you have it there are _stacks_ of neat features and a really 
> solid performance.
> I am especialy fond of the ability to put java into triggers (we send 
> SNMP traps to
> ops console when specific error conditions occur on inserts) and the 
> whole oracle
> Text and XML integration has saved me _months_ of development time on
> various project.

Ditto with PostgreSQL.  Except that usually triggers are written in 
PLPGSQL, Perl, or C.   I don't know whether PHP, Python, or Java support 
triggers yet but I am sure that they will soon :-)

Anyway.....  People's main gripes regarding PostgreSQL tend to come down to:

1)  Slow performance under heavy load.  Historically (prior to 7.4), 
PostgreSQL installed with very conservative memory settings, allowing it 
to run on pretty much any system made after the 1970's (ok, that is an 
overstatement but you get the idea).  It required tuning to get good 
performance under heavy concurrent use.  Nowadays, it does a better job 
of autodetecting settings, but if you need a *lot* of concurrent 
connections, you will still want to do some tuning.

2)  Historically, the alter table command was a bear.  Nowadays it is 
better.

3)  PostgreSQL doesn't ship with a GUI interface, so go get phppgadmin, 
Pgaccess, or Pgadmin III.

The selling points are:

1)  Extremely good performance under load (+/- 10% compared to 
commercial RDBMS's when properly tuned)
2)  Extensible data types
3)  User defined functions in a wide variety of languages including 
Java, TCL, Perl, Bash(!), Python, PHP, and more.
4)  Extreme care taken on making sure your data is consistant and 
meaningful.  Compared to MySQL which does not take so many precautions, 
PostgreSQL is the way to go.  As an aside, PostgreSQL and Oracle differ 
in whether they consider empty strings to be synonymous with NULL 
values.  Oracle says Yes, while PostgreSQL (and iirc the ANSI standard) 
says No, but this is a minor point which is usually academic.

But whatever you do, don't trust your accounting information to MySQL.

Best Wishes,
Chris Travers
Metatron Technology Consulting
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chris.vcf
Type: text/x-vcard
Size: 127 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20050313/b4814b5d/chris.vcf