| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Work with all your cloud files (Drive, Dropbox, and Slack and Gmail attachments) and documents (Google Docs, Sheets, and Notion) in one place. Try Dokkio (from the makers of PBworks) for free. Now available on the web, Mac, Windows, and as a Chrome extension!

View
 

Refactoring Databases Evolutionary Database Design

Page history last edited by Nathan T Suver 2 years, 8 months ago

Summary:

 

This book proposes using small, evolutionary changes to achieve database optimization through agile processes.  The book is formatting a little like a cookbook, with recipes for achieving better database design.  Many patterns presented also present the associated anti-pattern, leaving the reader to decide which benefits of a particular approach are suited for their needs.

 

Discussion of this particular type of refactor is on page 257 under the "Migrate Method from Database" pattern.  Reasons for performing this pattern include:

  • Supporting variability as business requirements change over time (e.g. easier to modify the procedure over time when business requirements start to diverge from the original implementation)
  • Increased portability (supports the ability for the method to be used with different database types in the future)
  • Increased scability (via the use of application servers)
  • Increased maintainability (better tooling for writing maintainable, testable code exists in Java and C#.  Easier to find programmers that have c# experience than it is to find programmers that have both c# and sql experience)

Reasons to NOT implement the pattern:

  • Reduced reusability (just about all modern languages know how to run a database command, making stored procedure calls convenient and ubiquitous.
  • Performance degradation: Moving data across the network creates latency that did not exist before, which will always slow down the procedure.

 

The discussion focuses on the overall benefits to the approach, but doesn't go into much detail on the nuances of such an approach, just the pros and cons of doing it. 

 

Extending the Approach:

  • Increasing scalability:  Collect metrics before and after refactoring (e.g. database server CPU load, disk access, procedure execution time, average user request completion time, etc..)  to show that overall system improvements in scalability 

 

source:

Ambler SW, Sadalage PJ (2006) Refactoring databases: Evolutionary database design. Addison Wesley, MA

 

relevant content:

 

page 257

Migrate Method from Database

Motivation:

1) Supports variability (e.g. application requirements begin to vary over time, in a way that multiple callers might use their own logic, this type of refactor allows for easier migration to varying use cases)

2) increased portability (reduced dependence on a particular rdbms)

3) increases scalability via the use of multiple application servers

4) increased maintainability.  Java and C#, etc, have good tool support for writing reusable, effective code.

 

Tradeoffs:

1) possible issues with performance degradation due to latency.

Comments (0)

You don't have permission to comment on this page.