> I'm a little confused about the whole database thing. I mean, I
> understand them and know what they are but which one should really be
> used for mission critical applications?
>
The one that is best for your application.
>
> So, my question is this...
>
> I'm a beginning Perl programmer trying to choose a database to learn and
> (eventually) use in mission critical applications. And I'm looking for
> something that quite scalable.
>
> The three databases I've read a little about are: MySQL, PostgreSQL, and
> BerkeleyDB.
>
> Can anyone offer some advise here?
>
Perl (see how I bring it ontopic so quickly? ) offers several tools
for abstracting database access, such that it doesn't matter WHICH
engine is behind the scenes. Learn to use DBI and friends and you can
move ably between databases.
If you're talking about a database that speaks SQL, clearly the "big
three" are MySQL, PostgreSQL and Oracle. There are on the order of a
dozen more that you'll see "in the wild" (e.g. DB2, Informix, Sybase)
all of which have their fans. This is what comes to mind when most
people think "database" (as opposed to seven years ago when you said
"database" and the Pavlovian response was "Oracle").
BerkeleyDB (and with it dbm, ndbm, and others of their ilk) are not so
much a "database" in the traditional sense, but a set of libraries for
adding structure to flat files.
There are perl modules that provide stripped down "SQL-like" access to
either dbm databases or a flat-file (DBD::DBM, DBD::SQLite) that can
plug in for some (but not all) 'database' applications.
As to which is "the best" ... None.
Every one has some tradeoff -- that's what engineering is all about --
you give some here, to get some there. Your job is to find out where
"here" and "there" are for your application.
Since I use all of MySQL, Postgres and Oracle in my daily life, I do
have opinions about them :)
Pros of MySQL: Huge volume of people who know how to use it,
reasonably fast, replication well supported.
Cons of MySQL: Even huger volume of people who THINK they know how to
use it, but don't. Consistently (n) years behind in feature
acceptance[1].
Pros of Postgres: Compulsive attention to SQL standard, rich
featureset (subselects, views, ACID that is actually atomic,
consistent, isolated and durable) bullet-proof.
Cons of Postgres: replication is ...challenging. Rarely wins in
database benchmarking contests.
Pros of Oracle: It can do *everything*. As the 900# gorilla in the
space, they can single-handedly declare what SQL is, and the rest will
follow.
Cons of Oracle: It can do *everything*. Configuration is tedious,
and the user tools are painful to use. That which is infinitely
configurable must be infinitely configured.
As to which to learn first -- my personal favorite is Postgres -- it
offers a good balance between performance and feature-set and is well
supported, with an active user community.
[1] The MySQL community (as a collective consciousness) tends to
poo-pooh any feature they don't currently support as frivolous,
unwise, or evil. Until such time as they support it, when it suddenly
becomes integral, intelligent and obviously correct. A couple of
years ago, I was having an animated discussion with someone as to why
my current employer used Pg instead of MySQL, and he said, "Well - we
have [that feature] now!" "Great! Take it back in time to 1998 when
we wrote all this code that needed it, and we chose Postgres!"
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Lawrence Statton - [EMAIL PROTECTED] s/aba/c/g
Computer software consists of only two components: ones and
zeros, in roughly equal proportions. All that is required is to
sort them into the correct order.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
