High level overview of databases, database environments, and data policy for employee on-boarding.

1. Welcome!
Databases 101

2. SQL Server
What is a database?
Database
Table
Rows
● Multiple SQL Server
instances per server are
possible
● Multiple databases per
SQL server are possible
● “Multiple Drawers”
Tables can have indexes
...but what’s an index?
● Think of an index at the back of a text book.
● Indexed on some specific column or columns
● This is important for performance when looking
up information.
● Why am I telling you this?
Image Credit: http://media.datadirect.com/download/docs/sequelnk/odbc30/uindex.htm
Image Credit: http://4vector.com/thumb_data/afd-

3. Relational Databases
Hierarchical DBS Relational DBS
Image Credit: IBM http://www.ibm.com/developerworks/xml/library/x-matters8/index.html?ca=drs

4. SQL Server instances...who uses them?
Development
QA
Stage
Development QA
CS
Application
s
Production
APIs
Reporting

5. Ok, so what is SQL?
SQL = Structured Query Language
● A 4th generation programming language for managing data held in relational
database management systems
● Based on relational algebra concepts
● Good news: Powerful but easy to use
● Bad news: Powerful but easy to use
SQL command categories:
● DDL (Data Definition Language) - CREATE TABLE, etc.
● DCL (Data Control Language) - GRANT, REVOKE, etc.
● DML (Data Manipulation Language) - INSERT, UPDATE, DELETE, SELECT
We’ll focus on a small subset of SQL commands within the DML category:
SELECT commands.

6. Anatomy of a SELECT statement
SELECT FirstName, LastName
FROM People
WHERE ID = 1234567
SELECT FirstName, LastName
FROM People
WHERE Department_ID = 56789
AND (LastName LIKE ‘Smith’ OR LastName LIKE ‘Bradford’)
SELECT FirstName, LastName
FROM People

7. Anatomy of a SELECT statement
WHERE clause:
● Acts as a filter. Only give me results
where x = y
● Compares the ID column against a
value or another column
SELECT FirstName, LastName
FROM People
WHERE Department_ID = 56789
AND (LastName LIKE ‘Smith’ OR LastName LIKE ‘Bradford’)
Multiple WHERE
filters
OR operator = Either of
these conditions can be true
SELECT FirstName, LastName
FROM People
SELECT command
Column names
FROM tablename
SELECT FirstName, LastName
FROM People
WHERE ID = 1234567

8. Locking, Blocking, and Deadlocking
Locking
● Locking is the restriction of data access to some data in the database. What does that mean? If
I’m working on a row of data, you can’t change it.
● Tables are shared resources. Lots of processes may be reading, inserting, updating, or deleting
from them at the same time.
● Locking enables these processes to occur in a managed, orderly fashion (e.g. Bank Account:
deduction from person A blocks a deduction from person B until deduction from person A is
complete).
Blocking
● When a table is locked by one process and another process attempts to access it, blocking
occurs.
● Blocking is normal to a point...we need it to maintain integrity...but it can be dangerous.
● Ways we manage blocking
○ Avoid unnecessary blocking by writing better code
○ Keep an eye on blocking with a Block Monitor to alert us if a block is out of control
○ Use NOLOCK when doing ad hoc queries - very important!

9. Locking, Blocking, and Deadlocking
SELECT FirstName, LastName
FROM People WITH (NOLOCK)
WHERE ID = 1234567
Query hint
Using the ‘WITH (NOLOCK) hint means you are forfeiting your right to exclusive
access to that data, and changes may occur while you are viewing it.
Why is that a good thing?
Why could that be a bad thing?

10. Locking, Blocking, and Deadlocking
** Always use the WITH (NOLOCK) syntax on your queries! **

11. Locking, Blocking, and Deadlocking
Deadlocking
Image Credit: http://www.sqlxl.com/images/sql_deadlock_image001.pngImage Credit:
Bye, bye

12. Dos and Don’ts
Do
● Use COUNT() function to see how many rows you are working on, before blindly
selecting back massive amounts of data:
SELECT COUNT(ID)
FROM People WITH (NOLOCK)
Column name
● Use TOP clause to view a subset of rows if you are investigating the type of data
in a table:
SELECT TOP 10 *
FROM People WITH (NOLOCK)
● Use WHERE clause whenever possible to avoid needless row retrieval:
SELECT TOP 10 *
FROM People WITH (NOLOCK)
WHERE LastName LIKE ‘Jones’

13. Dos and Don’ts
Don’t
● Use SELECT * to pull back all data when all data is not needed
SELECT *
FROM People
● Use negative logic like: <>, NOT LIKE, NOT EXISTS
SELECT TOP 10 *
FROM People
WHERE LastName NOT LIKE ‘Jones’
● Join more than three or four tables when possible:
SELECT p.ID
FROM People p
INNER JOIN Department d ON d.Dept_ID = p.Dept_ID
INNER JOIN…
INNER JOIN…
WHERE LastName LIKE ‘Jones’

14. Joining Tables
The power of relational databases lies in the ability to join data between tables. Most tables will
have relationships to other tables in the database and following these ‘threads’ between tables
allows us to efficiently store and retrieve data:
SELECT pl.Title
FROM Publication pl WITH (NOLOCK)
INNER JOIN Publisher p WITH (NOLOCK) ON p.PubID = pl.PubID
WHERE p.PubAddress LIKE ‘%New York%’
Publisher
Author
Publication

15. Joining Tables
Avoid Cartesian products!!
A cartesian product occurs when you use CROSS JOIN without WHERE filters. This forces the
query to join EVERY row to EVERY OTHER row in the joined tables
SELECT pl.Title
FROM Publication pl WITH (NOLOCK)
CROSS JOIN Publisher p WITH (NOLOCK)
WHERE p.PubAddress LIKE ‘%New York%’---------------------------------------------------

16. Stored Procedures
● Stored procedures = encapsulated code
● They are like tiny little applications - they contain SQL code that, when called, will run
the same way everytime
● Example:
Stored Procedure:
cs_EmployeeNames
Stored Procedure code:
Select FirstName, LastName
FROM People
This...
EXEC cs_EmployeeNames
...gives you the same results as this
Select FirstName, LastName
FROM People

17. Stored Procedures
Stored procedure auditing
● Tracks who ran what stored procedure
● What parameters where passed in (in other words, for which client was the sp run?)
● When it was run
Image Credit: http://www.keepcalm-o-matic.co.uk/p/big-brother-is-watching-you-13/

18. Data Policy
● Do not read/interpret data for your own personal use
● Be VERY conscientious of how you communicate data back and forth to customers. Our cs Chat is secure, but email is
not...never pass sensitive data via email, other IM clients, fax, etc. SFTP is the only acceptable way to pass sensitive data.
● Do not share customer data across customer boundaries - be careful of even off handed comments on the phone (Oh, your
fill rate is this but so-and-so is that, etc.)
● Do not take data home or outside of company controlled devices (e.g. your laptop) unless absolutely necessary to complete
your work. This includes thumb drives, printed material, etc.
● Be absolutely certain the client you are sharing data with is who you think it is. This is especially tricky over the phone. If
unsure, end the conversation and call them back at the verified contact number to ensure you are speaking with the correct
person.
● Do not share usernames and passwords. Ever. (This includes SQL users, PCs, Customer data, etc.)
● Do not log in with your credential for someone else. Ever.
● This can seem innocuous, but you are liable for what they do under your credentials.
● Check with IT before storing client or company data anywhere outside of company approved devices or drives (eg. Google
docs, Evernote, etc.) This is very tightly controlled.

19. Don’t be afraid of the DBAs
And we’re normal.
Really.
No, seriously.
We’re here to help.