SQL Server May Let You Do It, But it Doesn’t Mean You Should Samantha Fahrmann s_2004fahrmann@hotmail.com Caliber Public Safety
About Me Application Developer – 7 years @slfahrmann on Twitter Working with SQL in a development role for 7 years Working with SQL in an Accidental DBA role for 4 years First Time Presenter
Agenda T-SQL Bad Habits Management Studio Bad Habits Database layout and design Maintenance, Configuration and Defaults The “I can’t believe you just did that” list
T-SQL Bad Habits Select * Cursors Where IntField = ‘1’ Coding in SQL – code reuse Functions in views Inline select Select * because It’s easy – I don’t know what I want. Just starting out – not looking forward. Cursors – there’s a time and place for it. But usually a better option – Search collection. Scalar value functions in column definitions in views – script Demo Inline select script demo
Management Studio Bad Habits Edit top 200 for small one field change Select top 1000 for 1 record Select top 1000 for getting what the table looks like – “What’s my column name?” Developers coming from Access – Go to Accidental Data modification – multi-tasking Do you really need to select all that data to make a change in one or two columns for a record? Select top 1000 – cause I’m not quite sure what record I need or the identity column to sort or filter on.
Database Layout and Design Column Based Settings Tables Not looking forward Data type abuse Normalization or lack there of… Indexing UniqueIdentifier as PK and Clustered Index Add a setting to application – add a column Did you consider design, how the data will change over time, what could be added later. Don’t know exactly what they want – default nvarchar(50), nvarchar(200), ntext – do you even need Unicode? SQL does have a max width for a table row – remember that. Violation SQL server does have max on column count and index count per table. Doesn’t mean you should ever get there. Developers adding indexes without understanding – Bit field indexes – Index on a single column every time one is added.
Maintenance, Configuration and Defaults Optimize For Ad-Hoc Workloads (Good Habit) Max Server Memory Database Creation Initial Size Growth Rate Auto Shrink Location on Disk TempDB Backups and Recovery Model Built in setting in configurations- Ad-Hoc not many reasons why not to use this – Database creation – using defaults- will not play nice down the road. Rubber band log files. You only have a C:\ Drive? Are you sure you know what you are doing? Sometimes I wonder about people. Backups – not having one – setting them and never checking them – where are they going? Database set to Full – we’ll just shrink regularly to maintain (Say What?!) Database set to Full – Single transaction log backup at same time every day with full backup – someone please explain the benefit of this to me? Log File growing out of control – we can fix this – just set it to simple right? That fixes everything! NO NO NO
I Can’t Believe You Just Did That! Shrink Database – “OH NO, there’s a little free space in there” NTEXT – “We’re just not sure what data will go there yet” Server uptime – 200+ days – “Are you sure you know what you’re doing?”
Questions?