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@xxxxxxxxxxxxxx [mailto:pgsql-general-owner@xxxxxxxxxxxxxx] On Behalf Of Lew Sent: Friday, November 02, 2007 1:50 AM To: pgsql-general@xxxxxxxxxxxxxx Subject: Re: young guy wanting (Postgres DBA) ammo Kevin Hunter wrote: > At 12:35a -0400 on 02 Nov 2007, Tom Lane wrote: >> Kevin Hunter <hunteke@xxxxxxxxxxx> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
