5 Things SQL Should Get Rid Of

Paul Randal was kind enough to tag me in his blog post, 5 Things SQL Should Get Rid Of. I’m running well behind the rest of the meme bloggers, and I’ve already read everything I would’ve said in other peoples’ posts. The good news is that I just got an email from Evil Jen (she’s an absolutely horrible DBA), so I’ll just pass on what she wrote:

Evil Jen says: 5 things SQL should get rid ofEvil Jen is a bad DBA

Locking and Isolation levels! Transactional consistency and locking just slow down the database. I use NOLOCK on everything anyway to speed things up, and voila! No more concurrency issues, no more deadlocks, and I never hear any complaints about query speed from the users!  Anything that keeps them out of my cube is a best practice in my book. Hopefully no one notices that their data gets overwritten periodically.

Clustered indexes. Why do we even have these? They’re too complicated…they do order data on disk, they don’t really order data on disk. And how are you supposed to pick what column they should go on?  I just give each table a clustered GUID PK, and I know they’re totally unique.  I’m sorry, fragmen-what?  Oh. Well, I told you clustered indexes were bad.

The transaction log. Again, why do we have this? All it does is slow down every single thing you want to do in the DB. Durability, blah blah, transaction log backups, blah, restore to point of failure, WHATEV. If the data were all THAT important, they would’ve hired a DBA who actually cared about data.

The 32 level nested limit on triggers. I know, you’re saying “wait, aren’t you all up in arms about things that slow down queries?” HAH! I’m a bad DBA…I don’t need to have consistently logical reasons. If I need to go out and add triggers to a system, I don’t want any lame-o artificial limits on what I want to do.

All those different roles and security granularity…things. I mean, seriously…who has time to lock down permissions, or put users into groups, and all that? I just give everyody system admin rights, and then nobody complains that they can’t run their TRUNCATE TABLE statements on production in the middle of the day. 

Hey, it’s their database. I’m not here to tell them how to use it. I’m just here to blame the network if something goes wrong.

-Evil Jen

4 thoughts on “5 Things SQL Should Get Rid Of”

  1. Pingback: Tweets that mention SQL Awesomesauce » Blog Archive » 5 Things SQL Should Get Rid Of -- Topsy.com

  2. SQLDenis

    You know there is this cool thing called DBCC SHRINKFILE, if you schedule it to run every 15 seconds it will be like having no transaction log 🙂

  4. Janice Lee

    Evil Jen, my sentiments exactly. The transaction log is useless! Printed your post out and showed it to the Senior DBA telling him in so many words that I’ve been right all along. (He recently had me put on probation after I shrunk some “supposedly” important files).

    Looks like I’m about to get fired though. Well…no point working with people who has yet to see the light, right?? Care to have me on your team? ;););)

    P.S. Love this! :p But no, I don’t have coffee coming out of my nose. That’s just gross! No offense to @onpnt 😉

Comments are closed.