25
Chapter 2: Data Architecture
2
Agile Modeling
Agile development is popular for good reasons. It gets the job done quickly and often produces a
better result than traditional methods. Agile development also fi ts well with database design and
development.The traditional waterfall process steps through four project phases: requirements gathering, design,
development, and implementation. Although this method may work well for some endeavors, when
creating software, the users often don’t know what they want until they see it, which pushes discovery
beyond the requirements gathering phase and into the development phase.Agile development addresses this problem by replacing the single long waterfall with numerous short
cycles or iterations. Each iteration builds out a working model that can be tested and enables users
to play with the software and further discover their needs. When users see rapid progress and trust
that new features can be added, they become more willing to allow features to be planned into the
life cycle of the software, instead of insisting that every feature be implemented in the next version.A project might consist of a dozen of these tight iterations; and with each iteration, more features are
fl eshed out in the database and code. The principle of extensibility, mentioned earlier in this chapter, is
highlighted by an agile development process; as you cycle through iterations, an extensible database
absorbs new business requirements with less refactoring. Frankly, this is how requirements evolve.
You never know everything up front, so plan for and embrace the idea that your database needs to
evolve along with the rest of the project. This might include time built into your schedule for design
refactoring, aligning database design tasks with iterative application coding cycles, or deferring design
decisions until requirements become more robust.Set-Based Queries
SQL Server is designed to handle data in sets. SQL is a declarative language, meaning that
the SQL query describes the problem, and the Query Optimizer generates an execution plan
to resolve the problem as a set.Iterative T-SQL code is code that acts upon data one row at a time instead of as a set. It is
typically implemented via cursors and forces the database engine to perform thousands of
wasteful single-row operations, instead of handling the problem in one larger, more effi -
cient set. The performance cost of these single-row operations is huge. Depending on the
task, SQL cursors perform about half as well as set-based code, and the performance differ-
ential grows with the size of the data. This is why set-based queries, based on an obvious
physical schema, are so critical to database performance.A good physical schema and set-based queries set up the database for excellent indexing,
further improving the performance of the query (refer to Figure 2-2).c02.indd 25c02.indd 25 7/30/2012 4:07:53 PM7/30/2012 4:07:53 PM
http://www.it-ebooks.info