Agile Database Design
Agile Database Design - 21st Century Solutions to an ... - Deinersoft
Agile Database Design - 21st Century Solutions to an ... - Deinersoft
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Agile</strong> <strong>Database</strong> <strong>Design</strong><br />
21 st Century Solutions to an Age Old Problem
And in the Beginning, IBM Created IMS…
And in the Beginning, IBM Created IMS…<br />
In 1966, IBM designs Information Management System (IMS)
And in the Beginning, IBM Created IMS…<br />
In 1966, IBM designs Information Management System (IMS)<br />
Hierarchical <strong>Database</strong> With Transaction Processing
And in the Beginning, IBM Created IMS…<br />
In 1966, IBM designs Information Management System (IMS)<br />
Hierarchical <strong>Database</strong> With Transaction Processing<br />
Presentation System Coordinating Multiple Input Terminals
And Life Was Harsh…
And Life Was Harsh…<br />
General purpose queries were a nightmare
And Life Was Harsh…<br />
General purpose queries were a nightmare<br />
User queries were not something that users could do
And Life Was Harsh…<br />
General purpose queries were a nightmare<br />
User queries were not something that users could do<br />
Updates to the database? They had a word for it back then
And Life Was Harsh…<br />
General purpose queries were a nightmare<br />
User queries were not something that users could do<br />
Updates to the database? They had a word for it back then<br />
“Don’t”
<strong>Database</strong> Updates in the Days of the Great Flood
<strong>Database</strong> Updates in the Days of the Great Flood<br />
Just adding a new aribute was a nightmare
<strong>Database</strong> Updates in the Days of the Great Flood<br />
Just adding a new aribute was a nightmare<br />
Men were men and sheep were… (well, you get the idea)
<strong>Database</strong> Updates in the Days of the Great Flood<br />
Just adding a new aribute was a nightmare<br />
Men were men and sheep were… (well, you get the idea)<br />
And IMS Administrators were manly men
And Out of the Muck Arose Relational <strong>Database</strong>s
And Out of the Muck Arose Relational <strong>Database</strong>s<br />
And life was good
And Out of the Muck Arose Relational <strong>Database</strong>s<br />
And life was good changed
And Out of the Muck Arose Relational <strong>Database</strong>s<br />
And life was good changed<br />
Users could now form their own ad-hoc queries
And Out of the Muck Arose Relational <strong>Database</strong>s<br />
And life was good changed<br />
Users could now form their own ad-hoc queries<br />
<strong>Database</strong> schema meant easier database updates
And Out of the Muck Arose Relational <strong>Database</strong>s<br />
And life was good changed<br />
Users could now form their own ad-hoc queries<br />
<strong>Database</strong> schema meant easier database updates<br />
But the world was still not a pleasant place
The Carefree Early Days
The Carefree Early Days<br />
Worries over efficiencies started to become evident
The Carefree Early Days<br />
Worries over efficiencies started to become evident<br />
Era of great debates of efficiency versus functionality
The Carefree Early Days<br />
Worries over efficiencies started to become evident<br />
Era of great debates of efficiency versus functionality<br />
Bales with balancing efficiencies, such as data normalization
The Carefree Early Days<br />
Worries over efficiencies started to become evident<br />
Era of great debates of efficiency versus functionality<br />
Bales with balancing efficiencies, such as data normalization<br />
Changes in databases still required careful planning
The Carefree Early Days<br />
Worries over efficiencies started to become evident<br />
Era of great debates of efficiency versus functionality<br />
Bales with balancing efficiencies, such as data normalization<br />
Changes in databases still required careful planning<br />
Updates still sometimes include nightmares
And Then the 80s Happened
And Then the 80s Happened<br />
Relational databases became a mainstay of business
And Then the 80s Happened<br />
Relational databases became a mainstay of business<br />
DBAs became the lords of their kingdoms
And Then the 80s Happened<br />
Relational databases became a mainstay of business<br />
DBAs became the lords of their kingdoms<br />
DBAs practices and procedures to tame the savage database
And Then the 80s Happened<br />
Relational databases became a mainstay of business<br />
DBAs became the lords of their kingdoms<br />
DBAs practices and procedures to tame the savage database<br />
DBAs took cues from earlier experiences of IMS Administration
And Then the 80s Happened<br />
Relational databases became a mainstay of business<br />
DBAs became the lords of their kingdoms<br />
DBAs practices and procedures to tame the savage database<br />
DBAs took cues from earlier experiences of IMS Administration<br />
Painstaking upfront analysis and complete upfront design
And Then the 80s Happened<br />
Relational databases became a mainstay of business<br />
DBAs became the lords of their kingdoms<br />
DBAs practices and procedures to tame the savage database<br />
DBAs took cues from earlier experiences of IMS Administration<br />
Painstaking upfront analysis and complete upfront design<br />
Carefully controlled administrator functionality
And Then the 80s Happened<br />
Relational databases became a mainstay of business<br />
DBAs became the lords of their kingdoms<br />
DBAs practices and procedures to tame the savage database<br />
DBAs took cues from earlier experiences of IMS Administration<br />
Painstaking upfront analysis and complete upfront design<br />
Carefully controlled administrator functionality<br />
Ivory tower mentality
The Rise of the BDUF
The Rise of the BDUF<br />
DBAs embraced BDUF mentality strongly
The Rise of the BDUF<br />
DBAs embraced BDUF mentality strongly<br />
Many DBAs took on the role of BA
The Rise of the BDUF<br />
DBAs embraced BDUF mentality strongly<br />
Many DBAs took on the role of BA<br />
DB technology was alien to most programmers
The Rise of the BDUF<br />
DBAs embraced BDUF mentality strongly<br />
Many DBAs took on the role of BA<br />
DB technology was alien to most programmers<br />
DBAs were required for the care and feeding of databases
The Rise of the BDUF<br />
DBAs embraced BDUF mentality strongly<br />
Many DBAs took on the role of BA<br />
DB technology was alien to most programmers<br />
DBAs were required for the care and feeding of databases<br />
They still do – think clustering indexes, etc.
The Rise of the BDUF<br />
DBAs embraced BDUF mentality strongly<br />
Many DBAs took on the role of BA<br />
DB technology was alien to most programmers<br />
DBAs were required for the care and feeding of databases<br />
They still do – think clustering indexes, etc.<br />
The “three schema architecture” paern
The Clash of the BDUF and <strong>Agile</strong>
The Clash of the BDUF and <strong>Agile</strong><br />
Two things changed and are still active today
The Clash of the BDUF and <strong>Agile</strong><br />
Two things changed and are still active today<br />
Object oriented thinking emerged
The Clash of the BDUF and <strong>Agile</strong><br />
Two things changed and are still active today<br />
Object oriented thinking emerged<br />
<strong>Agile</strong> development replaced “design once, for the ages” mentality
The Clash of the BDUF and <strong>Agile</strong><br />
Two things changed and are still active today<br />
Object oriented thinking emerged<br />
<strong>Agile</strong> development replaced “design once, for the ages” mentality<br />
<strong>Agile</strong> teams thrive on generalized specialist collaboration
The Clash of the BDUF and <strong>Agile</strong><br />
Two things changed and are still active today<br />
Object oriented thinking emerged<br />
<strong>Agile</strong> development replaced “design once, for the ages” mentality<br />
<strong>Agile</strong> teams thrive on generalized specialist collaboration<br />
Some DBAs don’t take kindly to that paradigm
The Clash of the BDUF and <strong>Agile</strong><br />
Two things changed and are still active today<br />
Object oriented thinking emerged<br />
<strong>Agile</strong> development replaced “design once, for the ages” mentality<br />
<strong>Agile</strong> teams thrive on generalized specialist collaboration<br />
Some DBAs don’t take kindly to that paradigm<br />
Many today still cling to their ivory towers
Why <strong>Agile</strong> Mentality Causes Problems With DB Development
Why <strong>Agile</strong> Mentality Causes Problems With DB Development<br />
Demand for a complete BDUF
Why <strong>Agile</strong> Mentality Causes Problems With DB Development<br />
Demand for a complete BDUF<br />
Lack of desire to work in an iteratively due to migration issues
Why <strong>Agile</strong> Mentality Causes Problems With DB Development<br />
Demand for a complete BDUF<br />
Lack of desire to work in an iteratively due to migration issues<br />
Schemas that are part of the physical database instance
Why <strong>Agile</strong> Mentality Causes Problems With DB Development<br />
Demand for a complete BDUF<br />
Lack of desire to work in an iteratively due to migration issues<br />
Schemas that are part of the physical database instance<br />
Vendor oriented optimizations create development challenges
<strong>Agile</strong> Developer Reactions to DBA Issues
<strong>Agile</strong> Developer Reactions to DBA Issues<br />
<strong>Agile</strong> teams have responded in many ways
<strong>Agile</strong> Developer Reactions to DBA Issues<br />
<strong>Agile</strong> teams have responded in many ways<br />
Assume the DBA role themselves
<strong>Agile</strong> Developer Reactions to DBA Issues<br />
<strong>Agile</strong> teams have responded in many ways<br />
Assume the DBA role themselves<br />
Make the DB obsolete, such as ORMs, NoSQL persistence, etc.
<strong>Agile</strong> Developer Reactions to DBA Issues<br />
<strong>Agile</strong> teams have responded in many ways<br />
Assume the DBA role themselves<br />
Make the DB obsolete, such as ORMs, NoSQL persistence, etc.<br />
Kludge the database
Should Agilists Be Calling BDUF DBAs Certifiably Insane?
Should Agilists Be Calling BDUF DBAs Certifiably Insane?<br />
BDUFers aren’t crazy people, even in an <strong>Agile</strong> world
Should Agilists Be Calling BDUF DBAs Certifiably Insane?<br />
BDUFers aren’t crazy people, even in an <strong>Agile</strong> world<br />
Their hearts are in the right place!
Should Agilists Be Calling BDUF DBAs Certifiably Insane?<br />
BDUFers aren’t crazy people, even in an <strong>Agile</strong> world<br />
Their hearts are in the right place!<br />
They want to get the design right
Should Agilists Be Calling BDUF DBAs Certifiably Insane?<br />
BDUFers aren’t crazy people, even in an <strong>Agile</strong> world<br />
Their hearts are in the right place!<br />
They want to get the design right<br />
They want to eliminate the waste of rework
Should Agilists Be Calling BDUF DBAs Certifiably Insane?<br />
BDUFers aren’t crazy people, even in an <strong>Agile</strong> world<br />
Their hearts are in the right place!<br />
They want to get the design right<br />
They want to eliminate the waste of rework<br />
They want documentation for for future generations
But What BDUFers Gloss Over Is That…
But What BDUFers Gloss Over Is That…<br />
Software is not the code that we write
But What BDUFers Gloss Over Is That…<br />
Software is not the code that we write<br />
Code makes it easier for others to follow what we did
But What BDUFers Gloss Over Is That…<br />
Software is not the code that we write<br />
Code makes it easier for others to follow what we did<br />
Writing software is really an extension of the design process
But What BDUFers Gloss Over Is That…<br />
Software is not the code that we write<br />
Code makes it easier for others to follow what we did<br />
Writing software is really an extension of the design process<br />
Writing software gives insights into the problems that we solve
But What BDUFers Gloss Over Is That…<br />
Software is not the code that we write<br />
Code makes it easier for others to follow what we did<br />
Writing software is really an extension of the design process<br />
Writing software gives insights into the problems that we solve<br />
Testing and debugging are design validation and refinement
But What BDUFers Gloss Over Is That…<br />
Software is not the code that we write<br />
Code makes it easier for others to follow what we did<br />
Writing software is really an extension of the design process<br />
Writing software gives insights into the problems that we solve<br />
Testing and debugging are design validation and refinement<br />
This is why <strong>Agile</strong> has us develop iteratively
<strong>Agile</strong>/XP Engineering Practices Aid the Process
<strong>Agile</strong>/XP Engineering Practices Aid the Process<br />
Notably TDD and CI
<strong>Agile</strong>/XP Engineering Practices Aid the Process<br />
Notably TDD and CI<br />
Minimize significant rework
<strong>Agile</strong>/XP Engineering Practices Aid the Process<br />
Notably TDD and CI<br />
Minimize significant rework<br />
Shorter iterations that get to working software
<strong>Agile</strong>/XP Engineering Practices Aid the Process<br />
Notably TDD and CI<br />
Minimize significant rework<br />
Shorter iterations that get to working software<br />
Know that your system is always working w/o manual re-testing
<strong>Agile</strong>/XP Engineering Practices Aid the Process<br />
Notably TDD and CI<br />
Minimize significant rework<br />
Shorter iterations that get to working software<br />
Know that your system is always working w/o manual re-testing<br />
Allows for refinements and optimizations
Getting DBAs Kicking and Screaming Into the 21 st Century
Getting DBAs Kicking and Screaming Into the 21 st Century<br />
Many DBAs are still from an earlier era in software development
Getting DBAs Kicking and Screaming Into the 21 st Century<br />
Many DBAs are still from an earlier era in software development<br />
Still influenced by thought leaders from the 70s and 80s
Getting DBAs Kicking and Screaming Into the 21 st Century<br />
Many DBAs are still from an earlier era in software development<br />
Still influenced by thought leaders from the 70s and 80s<br />
Still think that software is different than persistence
Getting DBAs Kicking and Screaming Into the 21 st Century<br />
Many DBAs are still from an earlier era in software development<br />
Still influenced by thought leaders from the 70s and 80s<br />
Still think that software is different than persistence<br />
Many have been untouched by OO on the community at large
Getting DBAs Kicking and Screaming Into the 21 st Century<br />
Many DBAs are still from an earlier era in software development<br />
Still influenced by thought leaders from the 70s and 80s<br />
Still think that software is different than persistence<br />
Many have been untouched by OO on the community at large<br />
<strong>Agile</strong> DB tools are few and far between
Types of Tools Needed for <strong>Agile</strong> <strong>Database</strong> Development
Types of Tools Needed for <strong>Agile</strong> <strong>Database</strong> Development<br />
<strong>Database</strong> Refactoring
Types of Tools Needed for <strong>Agile</strong> <strong>Database</strong> Development<br />
<strong>Database</strong> Refactoring<br />
Incremental Data Modeling
Types of Tools Needed for <strong>Agile</strong> <strong>Database</strong> Development<br />
<strong>Database</strong> Refactoring<br />
Incremental Data Modeling<br />
<strong>Database</strong> Regression Testing
Types of Tools Needed for <strong>Agile</strong> <strong>Database</strong> Development<br />
<strong>Database</strong> Refactoring<br />
Incremental Data Modeling<br />
<strong>Database</strong> Regression Testing<br />
Configuration and Management of <strong>Database</strong> Artifacts
Types of Tools Needed for <strong>Agile</strong> <strong>Database</strong> Development<br />
<strong>Database</strong> Refactoring<br />
Incremental Data Modeling<br />
<strong>Database</strong> Regression Testing<br />
Configuration and Management of <strong>Database</strong> Artifacts<br />
Developer Sandboxes
<strong>Database</strong> Refactoring?
<strong>Database</strong> Refactoring?<br />
“Refactoring <strong>Database</strong>s: Evolutionary <strong>Database</strong> <strong>Design</strong>”
<strong>Database</strong> Refactoring?<br />
“Refactoring <strong>Database</strong>s: Evolutionary <strong>Database</strong> <strong>Design</strong>”<br />
“Refactoring: Improving the <strong>Design</strong> of Existing Code”
<strong>Database</strong> Refactoring?<br />
“Refactoring <strong>Database</strong>s: Evolutionary <strong>Database</strong> <strong>Design</strong>”<br />
“Refactoring: Improving the <strong>Design</strong> of Existing Code”<br />
<strong>Database</strong> refactoring is similar to code refactoring
<strong>Database</strong> Refactoring?<br />
“Refactoring <strong>Database</strong>s: Evolutionary <strong>Database</strong> <strong>Design</strong>”<br />
“Refactoring: Improving the <strong>Design</strong> of Existing Code”<br />
<strong>Database</strong> refactoring is similar to code refactoring<br />
Structural aspects of the schema
<strong>Database</strong> Refactoring?<br />
“Refactoring <strong>Database</strong>s: Evolutionary <strong>Database</strong> <strong>Design</strong>”<br />
“Refactoring: Improving the <strong>Design</strong> of Existing Code”<br />
<strong>Database</strong> refactoring is similar to code refactoring<br />
Structural aspects of the schema<br />
Functional aspects of the <strong>Database</strong>
<strong>Database</strong> Refactoring?<br />
“Refactoring <strong>Database</strong>s: Evolutionary <strong>Database</strong> <strong>Design</strong>”<br />
“Refactoring: Improving the <strong>Design</strong> of Existing Code”<br />
<strong>Database</strong> refactoring is similar to code refactoring<br />
Structural aspects of the schema<br />
Functional aspects of the <strong>Database</strong><br />
Testing of the change
A Sample <strong>Database</strong> Refactoring
A Sample <strong>Database</strong> Refactoring<br />
Split Column Paern – Replace a single column with 2 or more
A Sample <strong>Database</strong> Refactoring<br />
Split Column Paern – Replace a single column with 2 or more<br />
Person table has FirstDate column
A Sample <strong>Database</strong> Refactoring<br />
Split Column Paern – Replace a single column with 2 or more<br />
Person table has FirstDate column<br />
Used for customer birthdate as well as employee hire date
A Sample <strong>Database</strong> Refactoring<br />
Split Column Paern – Replace a single column with 2 or more<br />
Person table has FirstDate column<br />
Used for customer birthdate as well as employee hire date<br />
We must support people who are customers and employees
A Sample <strong>Database</strong> Refactoring<br />
Split Column Paern – Replace a single column with 2 or more<br />
Person table has FirstDate column<br />
Used for customer birthdate as well as employee hire date<br />
We must support people who are customers and employees<br />
You’ve got a problem. Ooops. Out of kludges…
A Sample <strong>Database</strong> Refactoring<br />
Split Column Paern – Replace a single column with 2 or more<br />
Person table has FirstDate column<br />
Used for customer birthdate as well as employee hire date<br />
We must support people who are customers and employees<br />
You’ve got a problem. Ooops. Out of kludges…<br />
Fix the schema to have BirthDate and HireDate columns
A Sample <strong>Database</strong> Refactoring<br />
Split Column Paern – Replace a single column with 2 or more<br />
Person table has FirstDate column<br />
Used for customer birthdate as well as employee hire date<br />
We must support people who are customers and employees<br />
You’ve got a problem. Ooops. Out of kludges…<br />
Fix the schema to have BirthDate and HireDate columns<br />
Behavioral semantics – update all FirstDate code
A Sample <strong>Database</strong> Refactoring<br />
Split Column Paern – Replace a single column with 2 or more<br />
Person table has FirstDate column<br />
Used for customer birthdate as well as employee hire date<br />
We must support people who are customers and employees<br />
You’ve got a problem. Ooops. Out of kludges…<br />
Fix the schema to have BirthDate and HireDate columns<br />
Behavioral semantics – update all FirstDate code<br />
Informational semantics – write migration script
A Sample <strong>Database</strong> Refactoring<br />
Split Column Paern – Replace a single column with 2 or more<br />
Person table has FirstDate column<br />
Used for customer birthdate as well as employee hire date<br />
We must support people who are customers and employees<br />
You’ve got a problem. Ooops. Out of kludges…<br />
Fix the schema to have BirthDate and HireDate columns<br />
Behavioral semantics – update all FirstDate code<br />
Informational semantics – write migration script<br />
Sounds easy enough…
What Makes <strong>Database</strong> Refactoring So Hard?
What Makes <strong>Database</strong> Refactoring So Hard?<br />
One word explains why database refactoring is so hard
What Makes <strong>Database</strong> Refactoring So Hard?<br />
One word explains why database refactoring is so hard<br />
Coupling
What Makes <strong>Database</strong> Refactoring So Hard?<br />
One word explains why database refactoring is so hard<br />
Coupling<br />
Coupling is the degree of dependence between two items
What Makes <strong>Database</strong> Refactoring So Hard?<br />
One word explains why database refactoring is so hard<br />
Coupling<br />
Coupling is the degree of dependence between two items<br />
High Coupling means a change in one needs a change in the other
What Makes <strong>Database</strong> Refactoring So Hard?<br />
One word explains why database refactoring is so hard<br />
Coupling<br />
Coupling is the degree of dependence between two items<br />
High Coupling means a change in one needs a change in the other<br />
Coupling is the “root of all evil” when in comes to DB refactoring
What Makes <strong>Database</strong> Refactoring So Hard?<br />
One word explains why database refactoring is so hard<br />
Coupling<br />
Coupling is the degree of dependence between two items<br />
High Coupling means a change in one needs a change in the other<br />
Coupling is the “root of all evil” when in comes to DB refactoring<br />
As more things get coupled to DB schema, the worse things get
The Inconvenient Truth About <strong>Database</strong> Schema Coupling
The Inconvenient Truth About <strong>Database</strong> Schema Coupling<br />
Your Application Source Code
The Inconvenient Truth About <strong>Database</strong> Schema Coupling<br />
Your Application Source Code<br />
Other Application Source Code
The Inconvenient Truth About <strong>Database</strong> Schema Coupling<br />
Your Application Source Code<br />
Other Application Source Code<br />
Data Load Source Code
The Inconvenient Truth About <strong>Database</strong> Schema Coupling<br />
Your Application Source Code<br />
Other Application Source Code<br />
Data Load Source Code<br />
Data Extract Source Code
The Inconvenient Truth About <strong>Database</strong> Schema Coupling<br />
Your Application Source Code<br />
Other Application Source Code<br />
Data Load Source Code<br />
Data Extract Source Code<br />
Persistence Frameworks and/or Layers
The Inconvenient Truth About <strong>Database</strong> Schema Coupling<br />
Your Application Source Code<br />
Other Application Source Code<br />
Data Load Source Code<br />
Data Extract Source Code<br />
Persistence Frameworks and/or Layers<br />
Data Migration Scripts
The Inconvenient Truth About <strong>Database</strong> Schema Coupling<br />
Your Application Source Code<br />
Other Application Source Code<br />
Data Load Source Code<br />
Data Extract Source Code<br />
Persistence Frameworks and/or Layers<br />
Data Migration Scripts<br />
Test Code
The Inconvenient Truth About <strong>Database</strong> Schema Coupling<br />
Your Application Source Code<br />
Other Application Source Code<br />
Data Load Source Code<br />
Data Extract Source Code<br />
Persistence Frameworks and/or Layers<br />
Data Migration Scripts<br />
Test Code<br />
Documentation
It’s the Tools, Stupid!
It’s the Tools, Stupid!<br />
Source code has refactorings issues, too!
It’s the Tools, Stupid!<br />
Source code has refactorings issues, too!<br />
But modern IDEs understand source code
It’s the Tools, Stupid!<br />
Source code has refactorings issues, too!<br />
But modern IDEs understand source code<br />
They can effect changes in affected source in one fell swoop
It’s the Tools, Stupid!<br />
Source code has refactorings issues, too!<br />
But modern IDEs understand source code<br />
They can effect changes in affected source in one fell swoop<br />
In other words, developers have power tools – IDEs!
It’s the Tools, Stupid!<br />
Source code has refactorings issues, too!<br />
But modern IDEs understand source code<br />
They can effect changes in affected source in one fell swoop<br />
In other words, developers have power tools – IDEs!<br />
Work is much more efficient with a power tool
It’s the Tools, Stupid!<br />
Source code has refactorings issues, too!<br />
But modern IDEs understand source code<br />
They can effect changes in affected source in one fell swoop<br />
In other words, developers have power tools – IDEs!<br />
Work is much more efficient with a power tool<br />
<strong>Database</strong> power tools are on the way, but that’s someday
It’s the Tools, Stupid!<br />
Source code has refactorings issues, too!<br />
But modern IDEs understand source code<br />
They can effect changes in affected source in one fell swoop<br />
In other words, developers have power tools – IDEs!<br />
Work is much more efficient with a power tool<br />
<strong>Database</strong> power tools are on the way, but that’s someday<br />
And we have work that must get done today
Tools, Smools. Look at the Big Picture!
Tools, Smools. Look at the Big Picture!<br />
So developers get some help from their tools. Big deal.
Tools, Smools. Look at the Big Picture!<br />
So developers get some help from their tools. Big deal.<br />
DBAs have even more baggage to deal with
Tools, Smools. Look at the Big Picture!<br />
So developers get some help from their tools. Big deal.<br />
DBAs have even more baggage to deal with<br />
Cultural impedance mismatch between OO types and DB types
Tools, Smools. Look at the Big Picture!<br />
So developers get some help from their tools. Big deal.<br />
DBAs have even more baggage to deal with<br />
Cultural impedance mismatch between OO types and DB types<br />
OO Types: Relational technology isn’t good to store objects
Tools, Smools. Look at the Big Picture!<br />
So developers get some help from their tools. Big deal.<br />
DBAs have even more baggage to deal with<br />
Cultural impedance mismatch between OO types and DB types<br />
OO Types: Relational technology isn’t good to store objects<br />
DB Types: Data Models trump objects in the enterprise
Tools, Smools. Look at the Big Picture!<br />
So developers get some help from their tools. Big deal.<br />
DBAs have even more baggage to deal with<br />
Cultural impedance mismatch between OO types and DB types<br />
OO Types: Relational technology isn’t good to store objects<br />
DB Types: Data Models trump objects in the enterprise<br />
The Truth: different skills, backgrounds, philosophies, ways to work
Tools, Smools. Look at the Big Picture!<br />
So developers get some help from their tools. Big deal.<br />
DBAs have even more baggage to deal with<br />
Cultural impedance mismatch between OO types and DB types<br />
OO Types: Relational technology isn’t good to store objects<br />
DB Types: Data Models trump objects in the enterprise<br />
The Truth: different skills, backgrounds, philosophies, ways to work<br />
The Beatles: Come together, right now, over me
The First, and Probably the Very Most Important Thing
The First, and Probably the Very Most Important Thing<br />
Start treating your databases like code!
The First, and Probably the Very Most Important Thing<br />
Start treating your databases like code!<br />
Impossible to over emphasize
The First, and Probably the Very Most Important Thing<br />
Start treating your databases like code!<br />
Impossible to over emphasize<br />
<strong>Agile</strong> developers are always in the habit of using their SCM tools
The First, and Probably the Very Most Important Thing<br />
Start treating your databases like code!<br />
Impossible to over emphasize<br />
<strong>Agile</strong> developers are always in the habit of using their SCM tools<br />
Any DDL that you’ve created
The First, and Probably the Very Most Important Thing<br />
Start treating your databases like code!<br />
Impossible to over emphasize<br />
<strong>Agile</strong> developers are always in the habit of using their SCM tools<br />
Any DDL that you’ve created<br />
Change scripts, Data migration scripts
The First, and Probably the Very Most Important Thing<br />
Start treating your databases like code!<br />
Impossible to over emphasize<br />
<strong>Agile</strong> developers are always in the habit of using their SCM tools<br />
Any DDL that you’ve created<br />
Change scripts, Data migration scripts<br />
Test data, Test cases, Test data generation code
The First, and Probably the Very Most Important Thing<br />
Start treating your databases like code!<br />
Impossible to over emphasize<br />
<strong>Agile</strong> developers are always in the habit of using their SCM tools<br />
Any DDL that you’ve created<br />
Change scripts, Data migration scripts<br />
Test data, Test cases, Test data generation code<br />
Documentation, Models, and everything else
The First, and Probably the Very Most Important Thing<br />
Start treating your databases like code!<br />
Impossible to over emphasize<br />
<strong>Agile</strong> developers are always in the habit of using their SCM tools<br />
Any DDL that you’ve created<br />
Change scripts, Data migration scripts<br />
Test data, Test cases, Test data generation code<br />
Documentation, Models, and everything else<br />
Follow this religiously, and everyone gets to play again!
What Sorts of <strong>Database</strong> Artifacts Should Be Under SCM Control?
What Sorts of <strong>Database</strong> Artifacts Should Be Under SCM Control?<br />
<strong>Database</strong> schema elements (tables, procedures, ...)
What Sorts of <strong>Database</strong> Artifacts Should Be Under SCM Control?<br />
<strong>Database</strong> schema elements (tables, procedures, ...)<br />
View definitions
What Sorts of <strong>Database</strong> Artifacts Should Be Under SCM Control?<br />
<strong>Database</strong> schema elements (tables, procedures, ...)<br />
View definitions<br />
Default values and data invariants for columns
What Sorts of <strong>Database</strong> Artifacts Should Be Under SCM Control?<br />
<strong>Database</strong> schema elements (tables, procedures, ...)<br />
View definitions<br />
Default values and data invariants for columns<br />
DB methods such as stored procedures, functions, and triggers
What Sorts of <strong>Database</strong> Artifacts Should Be Under SCM Control?<br />
<strong>Database</strong> schema elements (tables, procedures, ...)<br />
View definitions<br />
Default values and data invariants for columns<br />
DB methods such as stored procedures, functions, and triggers<br />
Referential integrity rules
What Sorts of <strong>Database</strong> Artifacts Should Be Under SCM Control?<br />
<strong>Database</strong> schema elements (tables, procedures, ...)<br />
View definitions<br />
Default values and data invariants for columns<br />
DB methods such as stored procedures, functions, and triggers<br />
Referential integrity rules<br />
Scaffolding (triggers, updateable views, ...) for refactorings
What Sorts of <strong>Database</strong> Artifacts Should Be Under SCM Control?<br />
<strong>Database</strong> schema elements (tables, procedures, ...)<br />
View definitions<br />
Default values and data invariants for columns<br />
DB methods such as stored procedures, functions, and triggers<br />
Referential integrity rules<br />
Scaffolding (triggers, updateable views, ...) for refactorings<br />
Documentation, and anything else that you may need again
Use a TDD Mentality For <strong>Database</strong> Refactorings
Use a TDD Mentality For <strong>Database</strong> Refactorings<br />
With a TDD mentality, you’ll have a beer outcome
Use a TDD Mentality For <strong>Database</strong> Refactorings<br />
With a TDD mentality, you’ll have a beer outcome<br />
One small step at a time
Use a TDD Mentality For <strong>Database</strong> Refactorings<br />
With a TDD mentality, you’ll have a beer outcome<br />
One small step at a time<br />
Write a test for each DB refactoring that you are about to do
Use a TDD Mentality For <strong>Database</strong> Refactorings<br />
With a TDD mentality, you’ll have a beer outcome<br />
One small step at a time<br />
Write a test for each DB refactoring that you are about to do<br />
Place the test under automated control
Use a TDD Mentality For <strong>Database</strong> Refactorings<br />
With a TDD mentality, you’ll have a beer outcome<br />
One small step at a time<br />
Write a test for each DB refactoring that you are about to do<br />
Place the test under automated control<br />
Perform the refactoring
Use a TDD Mentality For <strong>Database</strong> Refactorings<br />
With a TDD mentality, you’ll have a beer outcome<br />
One small step at a time<br />
Write a test for each DB refactoring that you are about to do<br />
Place the test under automated control<br />
Perform the refactoring<br />
Be sure you haven’t regressed any prior changes in DB or code
A Side Note on the Role of Continuous Integration
A Side Note on the Role of Continuous Integration<br />
A natural implication of TDD mindset is to use CI
A Side Note on the Role of Continuous Integration<br />
A natural implication of TDD mindset is to use CI<br />
When thinking of what a good CI solution looks like, think CRISP
A Side Note on the Role of Continuous Integration<br />
A natural implication of TDD mindset is to use CI<br />
When thinking of what a good CI solution looks like, think CRISP<br />
Complete
A Side Note on the Role of Continuous Integration<br />
A natural implication of TDD mindset is to use CI<br />
When thinking of what a good CI solution looks like, think CRISP<br />
Complete<br />
Repeatable
A Side Note on the Role of Continuous Integration<br />
A natural implication of TDD mindset is to use CI<br />
When thinking of what a good CI solution looks like, think CRISP<br />
Complete<br />
Repeatable<br />
Informative
A Side Note on the Role of Continuous Integration<br />
A natural implication of TDD mindset is to use CI<br />
When thinking of what a good CI solution looks like, think CRISP<br />
Complete<br />
Repeatable<br />
Informative<br />
Schedulable
A Side Note on the Role of Continuous Integration<br />
A natural implication of TDD mindset is to use CI<br />
When thinking of what a good CI solution looks like, think CRISP<br />
Complete<br />
Repeatable<br />
Informative<br />
Schedulable<br />
Portable
The Four Ways to Manage Your <strong>Database</strong> and Its Schema
The Four Ways to Manage Your <strong>Database</strong> and Its Schema<br />
Really only four distinct ways to manage your DB schema<br />
“Give Me a Good BDUF Anytime!”<br />
“Let Those Who Ride Decide!”<br />
“Roll Your Own Version Control”<br />
“Use a Power Tool”
Door #1 – Give Me a Good BDUF Anytime!
Door #1 – Give Me a Good BDUF Anytime!<br />
If can know everything up front, we only have to do the work once
Door #1 – Give Me a Good BDUF Anytime!<br />
If can know everything up front, we only have to do the work once<br />
Would never have to refactor – perfect the first time!
Door #1 – Give Me a Good BDUF Anytime!<br />
If can know everything up front, we only have to do the work once<br />
Would never have to refactor – perfect the first time!<br />
No waste due to rework
Door #1 – Give Me a Good BDUF Anytime!<br />
If can know everything up front, we only have to do the work once<br />
Would never have to refactor – perfect the first time!<br />
No waste due to rework<br />
But we never know everything up front, and/or it will change
Door #1 – Give Me a Good BDUF Anytime!<br />
If can know everything up front, we only have to do the work once<br />
Would never have to refactor – perfect the first time!<br />
No waste due to rework<br />
But we never know everything up front, and/or it will change<br />
So, this is prey much wishful thinking
Door #1 – Give Me a Good BDUF Anytime!<br />
If can know everything up front, we only have to do the work once<br />
Would never have to refactor – perfect the first time!<br />
No waste due to rework<br />
But we never know everything up front, and/or it will change<br />
So, this is prey much wishful thinking<br />
Not really practical
Door #1 – Give Me a Good BDUF Anytime!<br />
If can know everything up front, we only have to do the work once<br />
Would never have to refactor – perfect the first time!<br />
No waste due to rework<br />
But we never know everything up front, and/or it will change<br />
So, this is prey much wishful thinking<br />
Not really practical<br />
Not as good as an iterative approach to database design
Door #2 – Let Those Who Ride Decide!
Door #2 – Let Those Who Ride Decide!<br />
The process here is to avoid a process
Door #2 – Let Those Who Ride Decide!<br />
The process here is to avoid a process<br />
Any developer can make whatever DB changes they want
Door #2 – Let Those Who Ride Decide!<br />
The process here is to avoid a process<br />
Any developer can make whatever DB changes they want<br />
At release, diff Prod against Dev DBs and see what changed
Door #2 – Let Those Who Ride Decide!<br />
The process here is to avoid a process<br />
Any developer can make whatever DB changes they want<br />
At release, diff Prod against Dev DBs and see what changed<br />
Write a magical migration script – beer yet, let DevOps do it!
Door #2 – Let Those Who Ride Decide!<br />
The process here is to avoid a process<br />
Any developer can make whatever DB changes they want<br />
At release, diff Prod against Dev DBs and see what changed<br />
Write a magical migration script – beer yet, let DevOps do it!<br />
But DB diffs do not show semantics of the change
Door #2 – Let Those Who Ride Decide!<br />
The process here is to avoid a process<br />
Any developer can make whatever DB changes they want<br />
At release, diff Prod against Dev DBs and see what changed<br />
Write a magical migration script – beer yet, let DevOps do it!<br />
But DB diffs do not show semantics of the change<br />
As in change of column name looks like delete followed by an add
Door #2 – Let Those Who Ride Decide!<br />
The process here is to avoid a process<br />
Any developer can make whatever DB changes they want<br />
At release, diff Prod against Dev DBs and see what changed<br />
Write a magical migration script – beer yet, let DevOps do it!<br />
But DB diffs do not show semantics of the change<br />
As in change of column name looks like delete followed by an add<br />
Woe unto the migration developer who forgets the semantics!
Door #3 – Roll Your Own Version Control
Door #3 – Roll Your Own Version Control<br />
Our code is in SCM to get all the right bits get wired together
Door #3 – Roll Your Own Version Control<br />
Our code is in SCM to get all the right bits get wired together<br />
Version the schema by GUID, CI build #, or something else unique
Door #3 – Roll Your Own Version Control<br />
Our code is in SCM to get all the right bits get wired together<br />
Version the schema by GUID, CI build #, or something else unique<br />
Keep the schema for the DB in the SCM with the code using it
Door #3 – Roll Your Own Version Control<br />
Our code is in SCM to get all the right bits get wired together<br />
Version the schema by GUID, CI build #, or something else unique<br />
Keep the schema for the DB in the SCM with the code using it<br />
Then at runtime, application asks the database for it’s version
Door #3 – Roll Your Own Version Control<br />
Our code is in SCM to get all the right bits get wired together<br />
Version the schema by GUID, CI build #, or something else unique<br />
Keep the schema for the DB in the SCM with the code using it<br />
Then at runtime, application asks the database for it’s version<br />
Wrong version?
Door #3 – Roll Your Own Version Control<br />
Our code is in SCM to get all the right bits get wired together<br />
Version the schema by GUID, CI build #, or something else unique<br />
Keep the schema for the DB in the SCM with the code using it<br />
Then at runtime, application asks the database for it’s version<br />
Wrong version?<br />
Application can refuse to run until updated
Door #3 – Roll Your Own Version Control<br />
Our code is in SCM to get all the right bits get wired together<br />
Version the schema by GUID, CI build #, or something else unique<br />
Keep the schema for the DB in the SCM with the code using it<br />
Then at runtime, application asks the database for it’s version<br />
Wrong version?<br />
Application can refuse to run until updated<br />
Or actually apply changes needed to get it to correct version
Door #3 – Roll Your Own Version Control<br />
Our code is in SCM to get all the right bits get wired together<br />
Version the schema by GUID, CI build #, or something else unique<br />
Keep the schema for the DB in the SCM with the code using it<br />
Then at runtime, application asks the database for it’s version<br />
Wrong version?<br />
Application can refuse to run until updated<br />
Or actually apply changes needed to get it to correct version<br />
Now this sounds like a plan!
Door #3 – Roll Your Own Version Control<br />
There are tools that can help us do this version control
Door #3 – Roll Your Own Version Control<br />
There are tools that can help us do this version control<br />
Automatic schema management and update products
Door #3 – Roll Your Own Version Control<br />
There are tools that can help us do this version control<br />
Automatic schema management and update products<br />
Most work by diff and update the schema based on the diffs
Door #3 – Roll Your Own Version Control<br />
There are tools that can help us do this version control<br />
Automatic schema management and update products<br />
Most work by diff and update the schema based on the diffs<br />
But that can lead to the sort of problems I discussed earlier
Door #3 – Roll Your Own Version Control<br />
There are tools that can help us do this version control<br />
Automatic schema management and update products<br />
Most work by diff and update the schema based on the diffs<br />
But that can lead to the sort of problems I discussed earlier<br />
We may end up doing things like delete and then re-add a column
Door #3 – Roll Your Own Version Control<br />
There are tools that can help us do this version control<br />
Automatic schema management and update products<br />
Most work by diff and update the schema based on the diffs<br />
But that can lead to the sort of problems I discussed earlier<br />
We may end up doing things like delete and then re-add a column<br />
When what we really wanted to do was just rename a column
Door #3 – Roll Your Own Version Control<br />
There are tools that can help us do this version control<br />
Automatic schema management and update products<br />
Most work by diff and update the schema based on the diffs<br />
But that can lead to the sort of problems I discussed earlier<br />
We may end up doing things like delete and then re-add a column<br />
When what we really wanted to do was just rename a column<br />
And bye-bye data…
Door #3 – Roll Your Own Version Control<br />
How about Ruby on Rails?
Door #3 – Roll Your Own Version Control<br />
How about Ruby on Rails?<br />
RoR can do an automatic ActiveRecordMigration
Door #3 – Roll Your Own Version Control<br />
How about Ruby on Rails?<br />
RoR can do an automatic ActiveRecordMigration<br />
Prey good solution for the problem that it addresses!
Door #3 – Roll Your Own Version Control<br />
How about Ruby on Rails?<br />
RoR can do an automatic ActiveRecordMigration<br />
Prey good solution for the problem that it addresses!<br />
But it has two shortcomings…
Door #3 – Roll Your Own Version Control<br />
How about Ruby on Rails?<br />
RoR can do an automatic ActiveRecordMigration<br />
Prey good solution for the problem that it addresses!<br />
But it has two shortcomings…<br />
ActiveRecord design paern less capable than many-to-many
Door #3 – Roll Your Own Version Control<br />
How about Ruby on Rails?<br />
RoR can do an automatic ActiveRecordMigration<br />
Prey good solution for the problem that it addresses!<br />
But it has two shortcomings…<br />
ActiveRecord design paern less capable than many-to-many<br />
Only rudimentary refactorings are supported
Door #3 – Roll Your Own Version Control<br />
Big problem when you have to build the migration tool yourself
Door #3 – Roll Your Own Version Control<br />
Big problem when you have to build the migration tool yourself<br />
Your job as a developer is not to write DB migration scripts
Door #3 – Roll Your Own Version Control<br />
Big problem when you have to build the migration tool yourself<br />
Your job as a developer is not to write DB migration scripts<br />
We do them because we have to
Door #3 – Roll Your Own Version Control<br />
Big problem when you have to build the migration tool yourself<br />
Your job as a developer is not to write DB migration scripts<br />
We do them because we have to<br />
We want to minimize the amount of time we spend doing them
Door #3 – Roll Your Own Version Control<br />
Big problem when you have to build the migration tool yourself<br />
Your job as a developer is not to write DB migration scripts<br />
We do them because we have to<br />
We want to minimize the amount of time we spend doing them<br />
Consider what’s involved with DDL syntax MySQL vs MS SQL
Door #3 – Roll Your Own Version Control<br />
Big problem when you have to build the migration tool yourself<br />
Your job as a developer is not to write DB migration scripts<br />
We do them because we have to<br />
We want to minimize the amount of time we spend doing them<br />
Consider what’s involved with DDL syntax MySQL vs MS SQL<br />
Even stupid things like specifying indexes on tables vary a lot
Door #3 – Roll Your Own Version Control<br />
Big problem when you have to build the migration tool yourself<br />
Your job as a developer is not to write DB migration scripts<br />
We do them because we have to<br />
We want to minimize the amount of time we spend doing them<br />
Consider what’s involved with DDL syntax MySQL vs MS SQL<br />
Even stupid things like specifying indexes on tables vary a lot<br />
Is that where you want to spend your time?
Door #4 – Use a Power Tool
Door #4 – Use a Power Tool<br />
RoR ActiveRecord::Migration and rake db:migrate are power tools
Door #4 – Use a Power Tool<br />
RoR ActiveRecord::Migration and rake db:migrate are power tools<br />
If Ruby On Rails is OK for development and deployment
Door #4 – Use a Power Tool<br />
RoR ActiveRecord::Migration and rake db:migrate are power tools<br />
If Ruby On Rails is OK for development and deployment<br />
And you never have to go beyond the ActiveRecord paern
Door #4 – Use a Power Tool<br />
RoR ActiveRecord::Migration and rake db:migrate are power tools<br />
If Ruby On Rails is OK for development and deployment<br />
And you never have to go beyond the ActiveRecord paern<br />
And you aren’t interested in more than simple DB refactorings
Door #4 – Use a Power Tool<br />
And, there’s a Microsoft solution, too!
Door #4 – Use a Power Tool<br />
And, there’s a Microsoft solution, too!<br />
Microsoft Visual Studio Team System <strong>Database</strong> Edition
Door #4 – Use a Power Tool<br />
And, there’s a Microsoft solution, too!<br />
Microsoft Visual Studio Team System <strong>Database</strong> Edition<br />
Rudimentary refactoring built into Visual Studio IDE
Door #4 – Use a Power Tool<br />
And, there’s a Microsoft solution, too!<br />
Microsoft Visual Studio Team System <strong>Database</strong> Edition<br />
Rudimentary refactoring built into Visual Studio IDE<br />
You can do things like rename columns with code impunity
Door #4 – Use a Power Tool<br />
And, there’s a Microsoft solution, too!<br />
Microsoft Visual Studio Team System <strong>Database</strong> Edition<br />
Rudimentary refactoring built into Visual Studio IDE<br />
You can do things like rename columns with code impunity<br />
With Microsoft deployment tools, automatic DB updates
Door #4 – Use a Power Tool<br />
And, there’s a Microsoft solution, too!<br />
Microsoft Visual Studio Team System <strong>Database</strong> Edition<br />
Rudimentary refactoring built into Visual Studio IDE<br />
You can do things like rename columns with code impunity<br />
With Microsoft deployment tools, automatic DB updates<br />
Not bad for a pure Microsoft shop
Door #4 – Use a Power Tool<br />
And, there’s a Microsoft solution, too!<br />
Microsoft Visual Studio Team System <strong>Database</strong> Edition<br />
Rudimentary refactoring built into Visual Studio IDE<br />
You can do things like rename columns with code impunity<br />
With Microsoft deployment tools, automatic DB updates<br />
Not bad for a pure Microsoft shop<br />
But if you’re deploying to something like Oracle…
Door #4 – Use a Power Tool<br />
And, there’s a Microsoft solution, too!<br />
Microsoft Visual Studio Team System <strong>Database</strong> Edition<br />
Rudimentary refactoring built into Visual Studio IDE<br />
You can do things like rename columns with code impunity<br />
With Microsoft deployment tools, automatic DB updates<br />
Not bad for a pure Microsoft shop<br />
But if you’re deploying to something like Oracle…<br />
It’s back to “write a migration program” time!
Door #4 – Use a Power Tool<br />
And then there’s open source solutions!
Door #4 – Use a Power Tool<br />
And then there’s open source solutions!<br />
Tools like Scriptella (hp://scriptella.javaforge.com)
Door #4 – Use a Power Tool<br />
And then there’s open source solutions!<br />
Tools like Scriptella (hp://scriptella.javaforge.com)<br />
Which is not bad…
Door #4 – Use a Power Tool<br />
And then there’s open source solutions!<br />
Tools like Scriptella (hp://scriptella.javaforge.com)<br />
Which is not bad…<br />
There is cross database SQL dialect support
Door #4 – Use a Power Tool<br />
And then there’s open source solutions!<br />
Tools like Scriptella (hp://scriptella.javaforge.com)<br />
Which is not bad…<br />
There is cross database SQL dialect support<br />
Similar to the Ant SQL Task
Door #4 – Use a Power Tool<br />
And then there’s open source solutions!<br />
Tools like Scriptella (hp://scriptella.javaforge.com)<br />
Which is not bad…<br />
There is cross database SQL dialect support<br />
Similar to the Ant SQL Task<br />
If you can do it in SQL, you can do it beer in Scriptella
Door #4 – Use a Power Tool<br />
And then there’s open source solutions!<br />
Tools like Scriptella (hp://scriptella.javaforge.com)<br />
Which is not bad…<br />
There is cross database SQL dialect support<br />
Similar to the Ant SQL Task<br />
If you can do it in SQL, you can do it beer in Scriptella<br />
It’s really a good way to write migration scripts manually
Door #4 – Use a Power Tool<br />
And then there’s open source solutions!<br />
Tools like Scriptella (hp://scriptella.javaforge.com)<br />
Which is not bad…<br />
There is cross database SQL dialect support<br />
Similar to the Ant SQL Task<br />
If you can do it in SQL, you can do it beer in Scriptella<br />
It’s really a good way to write migration scripts manually<br />
But not as fully functional as my favorite…
Door #4 – Use a Power Tool<br />
And then there’s open source solutions!<br />
Tools like Scriptella (hp://scriptella.javaforge.com)<br />
Which is not bad…<br />
There is cross database SQL dialect support<br />
Similar to the Ant SQL Task<br />
If you can do it in SQL, you can do it beer in Scriptella<br />
It’s really a good way to write migration scripts manually<br />
But not as fully functional as my favorite…<br />
LiquiBase (hp://www.liquibase.org/)
LiquiBase – The 21 st Century Solution
LiquiBase – The 21 st Century Solution<br />
Deep cross database SQL dialect support
LiquiBase – The 21 st Century Solution<br />
Deep cross database SQL dialect support<br />
All configuration is kept in XML – SCM friendly
LiquiBase – The 21 st Century Solution<br />
Deep cross database SQL dialect support<br />
All configuration is kept in XML – SCM friendly<br />
Works from command line, Ant, Maven
LiquiBase – The 21 st Century Solution<br />
Deep cross database SQL dialect support<br />
All configuration is kept in XML – SCM friendly<br />
Works from command line, Ant, Maven<br />
Servlet Listener, Grails, Spring and Eclipse or standalone IDE
LiquiBase – The 21 st Century Solution<br />
Deep cross database SQL dialect support<br />
All configuration is kept in XML – SCM friendly<br />
Works from command line, Ant, Maven<br />
Servlet Listener, Grails, Spring and Eclipse or standalone IDE<br />
Manage production and/or test databases
LiquiBase – The 21 st Century Solution<br />
Deep cross database SQL dialect support<br />
All configuration is kept in XML – SCM friendly<br />
Works from command line, Ant, Maven<br />
Servlet Listener, Grails, Spring and Eclipse or standalone IDE<br />
Manage production and/or test databases<br />
Can handle multiple machines to databases concurrently
LiquiBase – The 21 st Century Solution<br />
Deep cross database SQL dialect support<br />
All configuration is kept in XML – SCM friendly<br />
Works from command line, Ant, Maven<br />
Servlet Listener, Grails, Spring and Eclipse or standalone IDE<br />
Manage production and/or test databases<br />
Can handle multiple machines to databases concurrently<br />
IDE supports over 30 of the Sadalage DB refactoring paerns
LiquiBase – The 21 st Century Solution<br />
Deep cross database SQL dialect support<br />
All configuration is kept in XML – SCM friendly<br />
Works from command line, Ant, Maven<br />
Servlet Listener, Grails, Spring and Eclipse or standalone IDE<br />
Manage production and/or test databases<br />
Can handle multiple machines to databases concurrently<br />
IDE supports over 30 of the Sadalage DB refactoring paerns<br />
Can do DB diffs if needed (i.e., for DBA production support)
LiquiBase – The 21 st Century Solution<br />
Deep cross database SQL dialect support<br />
All configuration is kept in XML – SCM friendly<br />
Works from command line, Ant, Maven<br />
Servlet Listener, Grails, Spring and Eclipse or standalone IDE<br />
Manage production and/or test databases<br />
Can handle multiple machines to databases concurrently<br />
IDE supports over 30 of the Sadalage DB refactoring paerns<br />
Can do DB diffs if needed (i.e., for DBA production support)<br />
Autogenerates database change documentation
Documentation? We don’t need no stinking documentation!
Documentation? We don’t need no stinking documentation!<br />
Think back to code. You want to help people get into the code.
Documentation? We don’t need no stinking documentation!<br />
Think back to code. You want to help people get into the code.<br />
But remember the DRY principle
Documentation? We don’t need no stinking documentation!<br />
Think back to code. You want to help people get into the code.<br />
But remember the DRY principle<br />
That’s why Java uses JavaDoc
Documentation? We don’t need no stinking documentation!<br />
Think back to code. You want to help people get into the code.<br />
But remember the DRY principle<br />
That’s why Java uses JavaDoc<br />
Autogenerated documentation is always up to date
Documentation? We don’t need no stinking documentation!<br />
Think back to code. You want to help people get into the code.<br />
But remember the DRY principle<br />
That’s why Java uses JavaDoc<br />
Autogenerated documentation is always up to date<br />
Keep remembering to treat your database like code
Documentation? We don’t need no stinking documentation!<br />
Think back to code. You want to help people get into the code.<br />
But remember the DRY principle<br />
That’s why Java uses JavaDoc<br />
Autogenerated documentation is always up to date<br />
Keep remembering to treat your database like code<br />
In code, some of the best documentation is good naming
Documentation? We don’t need no stinking documentation!<br />
Think back to code. You want to help people get into the code.<br />
But remember the DRY principle<br />
That’s why Java uses JavaDoc<br />
Autogenerated documentation is always up to date<br />
Keep remembering to treat your database like code<br />
In code, some of the best documentation is good naming<br />
Most databases have serious naming limitations
Documentation? We don’t need no stinking documentation!<br />
Think back to code. You want to help people get into the code.<br />
But remember the DRY principle<br />
That’s why Java uses JavaDoc<br />
Autogenerated documentation is always up to date<br />
Keep remembering to treat your database like code<br />
In code, some of the best documentation is good naming<br />
Most databases have serious naming limitations<br />
And, it can be really good to know who did what and when
Sample Liquibase Changelog
Sample Liquibase DBDoc
LiquiBase Supported Refactorings
LiquiBase Supported Refactorings<br />
<strong>Design</strong>ed for Sadalage and Ambler refactoring paerns
LiquiBase Supported Refactorings<br />
<strong>Design</strong>ed for Sadalage and Ambler refactoring paerns<br />
Six categories of transforming operations
LiquiBase Supported Refactorings<br />
<strong>Design</strong>ed for Sadalage and Ambler refactoring paerns<br />
Six categories of transforming operations<br />
Structural Refactorings
LiquiBase Supported Refactorings<br />
<strong>Design</strong>ed for Sadalage and Ambler refactoring paerns<br />
Six categories of transforming operations<br />
Structural Refactorings<br />
Data Quality Refactorings
LiquiBase Supported Refactorings<br />
<strong>Design</strong>ed for Sadalage and Ambler refactoring paerns<br />
Six categories of transforming operations<br />
Structural Refactorings<br />
Data Quality Refactorings<br />
Referential Integrity Refactorings
LiquiBase Supported Refactorings<br />
<strong>Design</strong>ed for Sadalage and Ambler refactoring paerns<br />
Six categories of transforming operations<br />
Structural Refactorings<br />
Data Quality Refactorings<br />
Referential Integrity Refactorings<br />
Architectural Refactorings
LiquiBase Supported Refactorings<br />
<strong>Design</strong>ed for Sadalage and Ambler refactoring paerns<br />
Six categories of transforming operations<br />
Structural Refactorings<br />
Data Quality Refactorings<br />
Referential Integrity Refactorings<br />
Architectural Refactorings<br />
Custom Refactorings
LiquiBase Supported Refactorings<br />
<strong>Design</strong>ed for Sadalage and Ambler refactoring paerns<br />
Six categories of transforming operations<br />
Structural Refactorings<br />
Data Quality Refactorings<br />
Referential Integrity Refactorings<br />
Architectural Refactorings<br />
Custom Refactorings<br />
Non-Refactoring Transformations
Dealing With the Hard Stuff
Dealing With the Hard Stuff<br />
LiquiBase makes things drop deal simple for most refactorings
Dealing With the Hard Stuff<br />
LiquiBase makes things drop deal simple for most refactorings<br />
But it’s not made of unobtainium
Dealing With the Hard Stuff<br />
LiquiBase makes things drop deal simple for most refactorings<br />
But it’s not made of unobtainium<br />
Try spliing a column like NAME into
Dealing With the Hard Stuff<br />
LiquiBase makes things drop deal simple for most refactorings<br />
But it’s not made of unobtainium<br />
Try spliing a column like NAME into<br />
FIRST_NAME, MIDDLE_NAME, and LAST_NAME
Dealing With the Hard Stuff<br />
LiquiBase makes things drop deal simple for most refactorings<br />
But it’s not made of unobtainium<br />
Try spliing a column like NAME into<br />
FIRST_NAME, MIDDLE_NAME, and LAST_NAME <br />
Sorry... You will have to write some code…
Dealing With the Hard Stuff<br />
LiquiBase makes things drop deal simple for most refactorings<br />
But it’s not made of unobtainium<br />
Try spliing a column like NAME into<br />
FIRST_NAME, MIDDLE_NAME, and LAST_NAME <br />
Sorry... You will have to write some code…<br />
LiquiBase has a framework for you in mind
Dealing With the Hard Stuff<br />
LiquiBase makes things drop deal simple for most refactorings<br />
But it’s not made of unobtainium<br />
Try spliing a column like NAME into<br />
FIRST_NAME, MIDDLE_NAME, and LAST_NAME <br />
Sorry... You will have to write some code…<br />
LiquiBase has a framework for you in mind<br />
Framework in liquibase.change.custom.*
Dealing With the Hard Stuff<br />
LiquiBase makes things drop deal simple for most refactorings<br />
But it’s not made of unobtainium<br />
Try spliing a column like NAME into<br />
FIRST_NAME, MIDDLE_NAME, and LAST_NAME <br />
Sorry... You will have to write some code…<br />
LiquiBase has a framework for you in mind<br />
Framework in liquibase.change.custom.* <br />
But you’re probably beer off with a command line driven script
Data Scrubbing
Data Scrubbing<br />
Constraints on the database’s informational semantics
Data Scrubbing<br />
Constraints on the database’s informational semantics<br />
The easy ones are default values, NULLness, and uniqueness
Data Scrubbing<br />
Constraints on the database’s informational semantics<br />
The easy ones are default values, NULLness, and uniqueness<br />
LiquiBase can handle all of those easy ones automatically
Data Scrubbing<br />
Constraints on the database’s informational semantics<br />
The easy ones are default values, NULLness, and uniqueness<br />
LiquiBase can handle all of those easy ones automatically<br />
But what about things like validation of credit card digits?
Data Scrubbing<br />
Constraints on the database’s informational semantics<br />
The easy ones are default values, NULLness, and uniqueness<br />
LiquiBase can handle all of those easy ones automatically<br />
But what about things like validation of credit card digits?<br />
Unhappily, that’s back to the hard stuff
Data Scrubbing<br />
Constraints on the database’s informational semantics<br />
The easy ones are default values, NULLness, and uniqueness<br />
LiquiBase can handle all of those easy ones automatically<br />
But what about things like validation of credit card digits?<br />
Unhappily, that’s back to the hard stuff<br />
Important to do, but very custom
How the <strong>Agile</strong> Delivery Team With <strong>Database</strong> Sensitivities Roles
How the <strong>Agile</strong> Delivery Team With <strong>Database</strong> Sensitivities Roles<br />
Make sure that data persistence concerns concern your team
How the <strong>Agile</strong> Delivery Team With <strong>Database</strong> Sensitivities Roles<br />
Make sure that data persistence concerns concern your team<br />
May take a new member for the team who has “data experience”
How the <strong>Agile</strong> Delivery Team With <strong>Database</strong> Sensitivities Roles<br />
Make sure that data persistence concerns concern your team<br />
May take a new member for the team who has “data experience”<br />
It’s not about generating SQL for your ORM mappings,
How the <strong>Agile</strong> Delivery Team With <strong>Database</strong> Sensitivities Roles<br />
Make sure that data persistence concerns concern your team<br />
May take a new member for the team who has “data experience”<br />
It’s not about generating SQL for your ORM mappings,<br />
handing it over to DevOps, and yelling “DEAL WITH IT!”
How the <strong>Agile</strong> Delivery Team With <strong>Database</strong> Sensitivities Roles<br />
Make sure that data persistence concerns concern your team<br />
May take a new member for the team who has “data experience”<br />
It’s not about generating SQL for your ORM mappings,<br />
handing it over to DevOps, and yelling “DEAL WITH IT!”<br />
It’s about developing a lile, testing a lot, rinsing and repeating
How the <strong>Agile</strong> Delivery Team With <strong>Database</strong> Sensitivities Roles<br />
Make sure that data persistence concerns concern your team<br />
May take a new member for the team who has “data experience”<br />
It’s not about generating SQL for your ORM mappings,<br />
handing it over to DevOps, and yelling “DEAL WITH IT!”<br />
It’s about developing a lile, testing a lot, rinsing and repeating<br />
It’s about reducing release and operational risk
How the <strong>Agile</strong> Delivery Team With <strong>Database</strong> Sensitivities Roles<br />
Make sure that data persistence concerns concern your team<br />
May take a new member for the team who has “data experience”<br />
It’s not about generating SQL for your ORM mappings,<br />
handing it over to DevOps, and yelling “DEAL WITH IT!”<br />
It’s about developing a lile, testing a lot, rinsing and repeating<br />
It’s about reducing release and operational risk<br />
It’s about the technical quality and usefulness of the database
How the <strong>Agile</strong> Delivery Team With <strong>Database</strong> Sensitivities Roles<br />
Make sure that data persistence concerns concern your team<br />
May take a new member for the team who has “data experience”<br />
It’s not about generating SQL for your ORM mappings,<br />
handing it over to DevOps, and yelling “DEAL WITH IT!”<br />
It’s about developing a lile, testing a lot, rinsing and repeating<br />
It’s about reducing release and operational risk<br />
It’s about the technical quality and usefulness of the database<br />
It’s about caring about the database as much as your code
Musings at the Crossroads of Agility and DBA Avenues
Musings at the Crossroads of Agility and DBA Avenues<br />
Will tools such as LiquiBase allow us to get rid of DBAs?
Musings at the Crossroads of Agility and DBA Avenues<br />
Will tools such as LiquiBase allow us to get rid of DBAs?<br />
Not at all
Musings at the Crossroads of Agility and DBA Avenues<br />
Will tools such as LiquiBase allow us to get rid of DBAs?<br />
Not at all<br />
DBAs have a lot of specialized knowledge that adds value
Musings at the Crossroads of Agility and DBA Avenues<br />
Will tools such as LiquiBase allow us to get rid of DBAs?<br />
Not at all<br />
DBAs have a lot of specialized knowledge that adds value<br />
They can handle things that developers don’t need or care about
Musings at the Crossroads of Agility and DBA Avenues<br />
Will tools such as LiquiBase allow us to get rid of DBAs?<br />
Not at all<br />
DBAs have a lot of specialized knowledge that adds value<br />
They can handle things that developers don’t need or care about<br />
Such as many of the non-functional database qualities
Musings at the Crossroads of Agility and DBA Avenues<br />
Will tools such as LiquiBase allow us to get rid of DBAs?<br />
Not at all<br />
DBAs have a lot of specialized knowledge that adds value<br />
They can handle things that developers don’t need or care about<br />
Such as many of the non-functional database qualities<br />
So, free them from the mundane that they have to do today
Musings at the Crossroads of Agility and DBA Avenues<br />
Will tools such as LiquiBase allow us to get rid of DBAs?<br />
Not at all<br />
DBAs have a lot of specialized knowledge that adds value<br />
They can handle things that developers don’t need or care about<br />
Such as many of the non-functional database qualities<br />
So, free them from the mundane that they have to do today<br />
Give them back the time to do what they were hired to do!
Musings at the Crossroads of Agility and DBA Avenues<br />
Will tools such as LiquiBase allow us to get rid of DBAs?<br />
Not at all<br />
DBAs have a lot of specialized knowledge that adds value<br />
They can handle things that developers don’t need or care about<br />
Such as many of the non-functional database qualities<br />
So, free them from the mundane that they have to do today<br />
Give them back the time to do what they were hired to do!<br />
We need to shun less, embrace and collaborate more
Fin
<strong>Agile</strong> <strong>Database</strong> <strong>Design</strong><br />
21 st Century Solutions to an Age Old Problem
Change language