Today we've spent a lot of the day in discussions with some folks about developers vs. DBAs, and how it's often the case that the two don't work together. Developers need to know the effect of their design choices on the database, and DBAs need to educate the developers. There should be a close working partnership between the two but bad communication and ignorance often get in the way – the DBAs don't know what the app devs want from them, and the app devs don't understand *why* the DBAs are so protective of the data tier. Neither side understands the day-to-day challenges of the other. Misunderstanding breeds conflict breeds animosity breeds intransigence and uncooperativeness. One of the eye-opening things sometimes is teaching DBA stuff to developers and vice-versa so they see the challenges and technology choice implications both ways.
We were pointed to this spoof video about a DBA-dev confrontation – http://www.benhblog.com/2009/03/linq-dba-vs-developer.html – pretty funny.
Kimberly was trawling around on that blog and found a quote: "I was surprised to learn that EF decided that since there was not a primary key it would just use all the non-nullable columns as a concatenated primary key. This might not be what you want." (where EF = Entity Framework)
Woah! Talk about the absolute worst key, and it does it automatically as the default! Kimberly blogged (see Seriously, are you kidding me?) about why this is bad, so I won't repeat that here – although as you can see it's set us both off on rants.
And that's why sometimes you can understand why the DBA doesn't want the developers anywhere near the database without taking a SQL breathalyzer test first.