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.