Ike Ellis, SQL Server MVP - presentation at SQL in the City At its most fun, software development is a team sport. Think of an NFL team. Does the quarterback know where the running back or tight-end will be? Does he do his job in a vacuum or with coordination and support from his teammates? However, if the teammate isn't doing what they're supposed to do, the play dissolves and leads not only to losing a game, but also individual dissatisfaction. Come to this session to learn how to coordinate and communicate as a team, improving individual and overall developer effectiveness.

1. 13 Mistakes
Common Mistakes Made By SQL Server Developers
and how to solve them
Ike Ellis, MVP
#SQLintheCityUS

2. They think testing is a waste of time
Write a line of code Deliver Code to Users
#SQLintheCityUS

3. #SQLintheCityUS

4. They refresh their development
environment with production data
1. Save Schema
2. Restore Database
3. Reset security
4. Restore Schema
#SQLintheCityUS

5. 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

6. 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

7. 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

8. 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

9. 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

10. They update production outside of
their development pipeline
• Changes are fast
• Bugs are fixed quickly
• The pipeline is too slow to release
#SQLintheCityUS

11. 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

12. They have three part
database names
I like to
reference
you!
Oooo, I like
to reference
you, too!
#SQLintheCityUS

13. Let’s get married!
#SQLintheCityUS

14. 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

15. They have four part
database names
I like to
reference
you!
Oooo, I like
to reference
you, too!
#SQLintheCityUS

16. Why is this bad?
• Servers are now anchored together
• It complicates building a test, QA, integration,
or canary environment
• Security concerns
#SQLintheCityUS

17. 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

18. 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

19. They don’t obfuscate production
data in all of their environments
I was your data,
but now you
don’t recognize
me

20. They don’t use a canary
If I die, you
better not
deploy!
#SQLintheCityUS

21. 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

22. 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

23. They write SQL Statements against tables
• More coupling
#SQLintheCityUS

24. 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_ellis
619.922.9801
ike@craftingbytes.com
#SQLintheCityUS