--- Greg Smith <gsmith@xxxxxxxxxxxxx> wrote: > On Fri, 2 Nov 2007, Kevin Hunter wrote: > > > 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." > > [snip] > > To step back for a second, the software industry as > a whole is going > through this phase right now where programmers are > more empowered than > ever to run complicated database-driven designs > without actually having to > be DBAs. It used to be that you "needed a DBA" for > every job like this > because they were the only people who knew how to > setup the database > tables at all, and once they were involved they also > (if they were any > good) did higher-level design planning, with > scalabilty in mind, and > worried about data integrity issues. > > Software frameworks like Ruby on Rails and Hibernate > have made it simple > for programmers to churn out code that operates on > databases without > having the slightest idea what is going on under the > hood. From a > programmer's perspective, the "better" database is > the one that requires > the least work to get running. This leads to > projects where a system that > worked fine "in development" crashes and burns once > it reaches a > non-trivial workload, because if you don't design > databases with an eye > towards scalability and integrity you don't > magically get either. > As one of these programmers, where is the best place to find the information I need to get it right. Finding information, and finding good information is not the same thing, and I am wary of 99% of what I find using google. Since you know what a DBA needs to know, I ask you where I can learn what you believe a good DBA needs to know. Or am I OK just relying on the documentation that comes with a given RDBMS (Postgres, MySQL, MS SQL, &c.)? Ted ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
