Let me start off by saying that SQL isn't my area of expertise, nor am I striving to be a DBA. I've worked at several companies, most of which have some app that runs on some year/flavor of SQL Server. None of the DBAs seemed to be obsessed with the issues that my current company has defined.This company didn't have a DBA initially, and only now has a contractor who only really helps when stuff goes awry. The managers have defined some best practices around how we should leverage SQL that I'm not convinced about. Any insight on how correct they are would be greatly appreciated.[b]1[/b] - Only execute queries against production [i]on[/i] production. "Connecting through SSMS from your dev box and running queries and schema updates can bring down the server"We have to RDP into our production server in order to write ad-hoc queries for troubleshooting or updating schemas. The problem is that we're such a small team with no QA team or unit tests (both of which are frowned upon as time-wasters) and we spend a lot of time debugging production code (and therefore production data). This means we're constantly bumping eachother off in the middle of working on things.[b]2[/b] - [i]Always[/i] use the NOLOCK hint on every select query.I'm inclined to be OK with this one when we can accept eventual consistency, but sometimes we need the data used by the app to be correct at the expense of a lock.[b]3[/b] - [i]Never[/i] use transactions. "Transactions can destroy the server"We're not allowed to use them when updating or deleting from tables to see if we'd be impacting the correct rows, or in code when we genuinely have a transaction. Instead, deleting or editing data manually requires that we fully backup the table using SELECT INTO, perhaps using a ROWCOUNT, and then hoping we don't have to restore from the backup.[b]4[/b] - [i]Never[/i] use any JOIN syntax. "Joins kill performance".We're expected to never use them. Needless to say sometimes we could write a simple JOIN and get what we need, or write a bunch of code that manually shoves data into a DTO. Our tables are indexed pretty well and performance is reviewed often.[b]5[/b] - [i]NEVER EVER EVER[/i] use SSMS's 'Edit Top 200 Rows' feature. "Using this locks the table when the window is left open".I've all but proven this one untrue, but I figured I'd ask anyway. When the window opens and is populating, I'm sure it does a one-time SELECT and doesn't use a NOLOCK, so we'd expect a short lock. Managers say that the table remains locked as long as the window is open and you're a horrible person if you do this.[b]6[/b] - [i]Never[/i] use stored procedures and don't use prepared statements.I never got a real explanation on this, which doesn't help my confusion.If it seems like I'm fishing to confirm my suspicions, it's because... well, I am. I've done enough research on each of them that has lead me to my current point of view, and when I present evidence to the best practice owners that is contrary to their statements, they ignore it or just tell me "don't do it". I'm going to stop pressing these issues regardless, but I'd love to have someone show me the light one way or the other so I don't hold on to misconceptions.
↧