Re: young guy wanting (Postgres DBA) ammo

Kevin Hunter wrote:
> At 12:35a -0400 on 02 Nov 2007, Tom Lane wrote:
>> Kevin Hunter <hunteke(at)earlham(dot)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