Good argument Andy, but I'd go further and say that really (and we probably all don't do this) what we need to do is NOT connect to production databases using accounts which have privileges that allow us to do damage without thinking. If we did, then which one we connected to wouldn't matter so much.
Problem is, it's that old compromise between being able to get the job done quickly and potentially damaging data by using an account which can do (almost) anything. All too easy to run a DML command which you intended for a dev or test DB against the live DB if you're not paying attention. A good argument for using non-sa accounts to access production DBs, unless absolutely necessary.
Master is at first sight not an obvious default as it contains some hyper important data which you don't want to corrupt, but the chances of accidentally updating/deleting a table in master which has the same name as an application table is pretty slim (unless you have weird developers). TempDB is a good candidate, but how about using Northwind, it doesn't matter much if you damage that? However, as noted previously, if your sysadmin a/c's are set to non-master it can be a problem in a DR situation, just when you don't need the hassle.
Whichever you choose, what I would strongly argue is that whilst it's not too important which particular db is default, it is probably a good idea never to default to a production database if there are dev/test/prod DBs on the same server. All too easy to run that update/truncate/drop table against an object with an identical name on live and test / live and dev, without engaging the brain. And yes, developers should be specifying the db/catalog they want to use in their connection strings - make 'em type! 🙂
Edited by - jonreade on 12/11/2002 07:28:03 AM