13 Mistakes Common Mistakes Made By SQL Server Developers

and how to solve them

Ike Ellis, MVP

#SQLintheCityUS

They think testing is a waste of time

Write a line of code Deliver Code to Users

#SQLintheCityUS

#SQLintheCityUS

They refresh their development

environment with production data

1. Save Schema2. Restore Database3. Reset security4. Restore Schema

#SQLintheCityUS

Why do they do this?

• Bugs in production are not reproducible in development

• They like seeing real data because it gives them better

testing of user interfaces and other things

• They like to be able to quickly answer questions

#SQLintheCityUS

What’s the downside?• Break tests because of old data

• Production data shouldn’t be seen by developers

• If development environments are on laptops, laptops get stolen and the company has lost production data

• Development servers are not usually backed up or secured properly

--And the development database is way too large---

#SQLintheCityUS

The dev environment

database is way too large• Why is it large?

• 15 years of data

• 75% of blob storage

– (PDFs, DOCs, AVIs)

• Lots of temp files, ETL imports, etc

Huge Bloated Database

#SQLintheCityUS

Why is that bad?• Database is not portable

• Multiple database environments are difficult to setup

• Hard to backup

• Hard to restore

• Hard to rebuild

• Hard to obfuscate

• Hard to query

• Development takes a really long time

• Big data costs money to store – big SANs – big developer laptops

#SQLintheCityUS

What’s the alternative• All development data is mocked

– Tests are repeatable

• Thread the buggy data, back through the development process

• Write a test that will fail with the new data

• Solve the issue

• Watch the test pass

• Check the test into source control

• Run the tests all the time

• Bug never happens again

I’m mocking your data

#SQLintheCityUS

They update production outside of

their development pipeline

• Changes are fast

• Bugs are fixed quickly

• The pipeline is too slow to release

#SQLintheCityUS

Why is this bad?

• Changes don’t get tested

• Changes don’t go back into the development

environment

• Changes can cause table and schema locks

and cause unexpected downtime

• These changes are often not peer reviewed

#SQLintheCityUS

They have three part

database namesI like to

reference you!

Oooo, I like to reference

you, too!

#SQLintheCityUS

Let’s get married!#SQLintheCityUS

But not all marriages are

happy…• Creates a tight coupling

• Moved together

– To a new server

• Have to be tested together

• Have to be integrated together

• Have to change together

• Have to be upgraded to a new version

• Have to be backed up together

• Have to be restored together

#SQLintheCityUS

They have four part

database namesI like to

reference you!

Oooo, I like to reference

you, too!

#SQLintheCityUS

Why is this bad?

• Servers are now anchored together

• It complicates building a test, QA, integration,

or canary environment

• Security concerns

#SQLintheCityUS

Developers share databases

• Source control history

– Generation 0 – Visual Source Safe

– Generation 1 – Subversion, TFS

– Generation 2- GIT, Mercurial

• Sharing databases is like going back to

generation 0.

#SQLintheCityUS

They think a rollback plan is undoing a

change outside of their development pipeline

• You can’t unbake this turkey

• You have to fix it

• Those fixes need to be tested – run it through again!

#SQLintheCityUS

They don’t obfuscate production

data in all of their environments

I was your data, but now you

don’t recognize me

They don’t use a canary

If I die, you better not

deploy!

#SQLintheCityUS

They let more than one application touch

a transactional database

• Microservices

• One application to one database

• Change together in the same pipeline

• Decouple everything, and I mean

everything, else

They don’t build their databases /

or they ignore compile errors

• Lots of processes, including RedGate CI Server, will do

this

• Show bad bindings

• Show bad columns

• Show sprocs that just won’t run

• Show tight-coupling

#SQLintheCityUS

They write SQL Statements against tables

• More coupling

#SQLintheCityUS

Ike Ellis• Crafting Bytes

– Small San Diego Software Studio– Modern web, mobile, Azure, SQL Server– Looking for future teammates!

• Book: Developing Azure Solutions• Podcast Guest:

– Talk Python to Me – Dec 2015

– .NET Rocks – Sept 2015• www.craftingbytes.com• blog.ikeellis.com• www.ikeellis.com• SDTIG – www.sdtig.com

Ike Ellis, MVP@ike_ellis619.922.9801ike@craftingbytes.com

#SQLintheCityUS