Re: young guy wanting (Postgres DBA) ammo - Mailing list pgsql-general

You know the old saying, tell a lie often enough and it becomes the
truth.

There are perceptions about databases out there that may not stand the
test of analysis.  But that really doesn't matter.  If you want to bring
down the perception, you need to use a different tact.  And that has
nothing to do with engineering. It's why successful companies have
marketing and sales groups.





-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Lew
Sent: Friday, November 02, 2007 1:50 AM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] young guy wanting (Postgres DBA) ammo

Kevin Hunter wrote:
> At 12:35a -0400 on 02 Nov 2007, Tom Lane wrote:
>> Kevin Hunter <hunteke@earlham.edu> writes:
>>> However, I'm not a DBA and only minimally know what's involved in
doing
>>> the job, so I don't have "ammo" to defend (or agree?) with my friend
>>> when he says that "Postgres requires a DBA and MySQL doesn't so
that's
>>> why they choose the latter.
>> He's full of it ... mysql is not any easier to run or tune.
>
> I expected as much, but would you give me something more than "Because
> Tom says so!"  Good enough for me, but not for a
> non-Postgres-indoctrinated person, I fear.  ;-)

MySQL comprises at least three different database engines, one of which
does
not support relational integrity.

Where I used to work, we developed a MySQL-based solution that required
foreign keys, so we used one of the engines that did support that.  The
"DBA"
for the production system forgot that instruction, and didn't use our
scripts,
I guess, because they configured the production system with the version
that
didn't support foreign keys.  Whoops.

MySQL's configuration contains similar tuning parameters to PG's.  All
you
need to do to gather "ammo" is to visit the respective web sites and
read up
on the configuration parameters for both.

By "MSSQL", what do you mean?  SQL Server?  That also needs some tuning.

Tuning, of course, is only one chore for a DBA.  Designing and
maintaining the
dataspace, performing backups without sacrificing (too much)
availability,
managing indexes, perhaps writing and maintaining stored procedures,
allocating usernames and passwords, creating and configuring schemas (or

whatever they're called in the particular product) are all part of DBA
work.

Does MySQL even support stored procedures?

PG surely doesn't need a DBA for small data stores, any more than MySQL
does.
  No DBMS will survive a heavy production environment for long without
someone
keeping an eye on it, particularly with large data sets.  Then you get
into
issues of RAID storage, clustering, failover and business continuity,
data
striping, segmenting the database so you can drop or maintain parts of
it
while leaving others in service, and much more are all part of any
high-volume
DBMS if you want it reliable.

Anybody who promulgates the idea that MySQL or SQL Server (assuming
that's the
one you meant) do not need a DBA simply have their head up their ass.
Someone
has to handle these tasks, and if the workload is high enough, that
needs to
be someone's primary duty.

Unless, of course, you simply don't care about your data.  The lifeblood
of
your enterprise.

--
Lew

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster