Databases Reference
In-Depth Information
Development tools
Developer training
Objective
normalization
Agility metrics
Architectures
Use cases
Figure 9.4
Factors such as development tools, training, architectures,
and use cases all impact developer agility. In order to do a fair comparison
of the impact of NoSQL architecture on agility, you need to normalize the
non-architecture components. Once you balance these factors, you can
compare how different NoSQL architectures drive the agility of a project.
narrowed down the options to a native
XML
database using XQuery and an
RDBMS
using a Java middle tier. For the sake of simplicity, effort is categorized using a scale of
1 to 5, where 1 is the least effort and 5 is the most effort. A sample of this analysis is
shown in table 9.1.
Table 9.1 High-level effort analysis to build a RESTful search service from an XML dataset. The steps
to build the service are counted and a rough effort level (1-5) is used to measure the difficulty of each
step.
NoSQL document store
SQL/Java method
1. Drag and drop XML file into data-
base collection (1)
2. Write XQuery (2)
3. Publish API document (1)
Total effort: 4 units
1. Inventory all XML elements (2)
2. Design data model (5)
3. Write create table statements (5)
4. Execute create table (1)
5. Convert XML into SQL insert statements (4)
6. Run load-data scripts (1)
7. Write SQL scripts to query data (3)
8. Create Java JDBC program to query data and Java REST pro-
grams to convert SQL results into XML (5)
9. Compile Java program and install on middle-tier server (2)
10. Publish API document (1)
Total effort: 29 units
Performing this type of analysis can show you how suitable an architecture is for a par-
ticular use case. Large projects may have many use cases, and you'll likely get conflict-
ing results. The key is to involve a diverse group of people to create a fair and objective
estimate of the total effort that's decoupled from background and training issues.
The amount of time you spend looking at the effort involved in each use case is up
to you and your team. Informal “thought experiments” work well if the team has peo-
ple with adequate experience in each alternative database and a high level of trust
