Appendix B - How the Developers Selected the NoSQL Databases

The developers at Adventure Works recognized that the different types of data required by the Shopping application would likely have different data storage and retrieval requirements. They could have implemented the system using a single relational database, but this approach would have entailed designing a collection of relational tables that might not be as well optimized for each business use case in the Shopping application as a non-relational approach would be. Therefore, the developers decided to adopt a strategy that utilized the most appropriate data storage mechanism for each form of data access performed by the application. The chapters in this guide describe how and why the developers at Adventure Works selected the various NoSQL databases that they used to store the information that the application uses, but the following list summarizes the decisions that the developers made:

• When a customer registers with the Shopping application, their details must be held in a safe and reliable database, and the login process that identifies the customer must be performed in a secure manner. The developers chose to implement the business functionality for the Shopping application as an ASP.NET web service built by using the MVC4 Web API. ASP.NET includes support for using SQL Server to manage and protect user account information, so the developers chose to store customer details in a SQL Server database.

  The Shopping application has to integrate with the warehousing and dispatching systems that handle inventory and order processing inside Adventure Works. These are transactional systems also based on SQL Server. They are outside the scope of the Shopping application, but the orders placed by customers have to be made available to them. Therefore, when a customer places an order, the details of the order are saved in the SQL Server database that these systems use.

  Note

  In the sample solution provided with the guide, the MvcWebApi web service writes the data directly to the SQL Server database used by the warehousing and dispatching systems. In the production environment described in Chapter 3 the details of orders are stored by using Windows Azure SQL Database in the cloud and Windows Azure Data Sync propagates this information to the SQL Server database running on-premises.

• When a customer logs in and adds items to their shopping cart, the application needs to retrieve and store the shopping cart in data storage. When the customer places an order, the shopping cart is no longer required and the application has to delete it from storage. The actual content of a shopping cart is immaterial to the data store, which can treat it as an opaque value. The important point is that the data store has to enable a shopping cart to be accessed quickly by using a unique key. For this reason, the developers chose to use a key/value store in the form of the Windows Azure Table service.

  Note

  You can also configure the user interface to retrieve product images from the Windows Azure Blob service. This is another example of a key/value store, although the MvcWebApi web service does not implement any specific functionality to support this mechanism; it is handled completely by the UI web application.

• When a customer browses products in the in the product catalog, the application has to quickly retrieve the data that describes category, subcategory, and product information. The application has to be able to filter this data by nonkey fields. For example, it has to fetch products by using the subcategory ID. The developers could have stored this information in a relational database, but the information held for each product could vary resulting in a complex schema, and retrieving data could result in the application having to perform a number of relational join operations across tables. For these reasons, the developers decided to structure the product and category information as a set of documents and store the information in a document database.

  For similar reasons, the developers chose to use a document database to store order history information. In this case, the application needs to be able to retrieve order history documents by using the OrderCode field. This field is not the key, and all order history documents that relate to the same order have the same value in this field.

• Although not part of the initial implementation, in the future the developers at Adventure Works may need to store information about website traffic to help assess how customers use the application and address possible performance issues. This data is likely to be high-growth and should support analytical processing to enable an administrator to determine the frequency with which customers visit each page in the Shopping application. These requirements are easily met by using a column-family database.

• When the application displays the details of a product, it also fetches production recommendations (other products that the customer may also be interested in). The application needs to retrieve this information based on potentially complex relationships between entities. Using a graph database helps to reduce the complexity of the queries that the application runs.

Next Topic | Previous Topic | Home | Community