Combining relational and NoSQL concepts in SQL Server with JSON

Intro

In this article we will see how you can combine NoSQL and relational concepts in SQL Server database.

We will see how you can transform tables to JSON objects and vice versa using FOR JSON and OPENJSON functions.

Description

Traditional relational schema design follow strict normalization approach – every logical entity is stored as a separate table and there are foreign key relationships between related entities. Imagine products that may have many reviews – you should create one table for products, another for reviews, propagate foreign key from product into reviews table, and add a foreign key relationship between them. 

Although this is a proper database design, you might end-up with a lot of tables and foreign key relationships, you will need to join tables every time you need to take product information, maintain indexes o foreign key columns to speed-up joins, etc. Example of query that read products and related reviews is shown in following example:

SELECT Production.Product.ProductID AS ID, Production.Product.Name, Color, ListPrice, 
 ReviewerName, ReviewDate, Rating
 FROM Production.Product
 JOIN Production.ProductReview
 ON Production.ProductReview.ProductID = Production.Product.ProductID

Every time you need to retrieve related reviews you need to join tables and you would probably need to create additional index on foreign key column in Review table. Results are shown in the following table:

On the client-side you probably need to process results and merge two 937 product rows as a single object with two related reviews items (e.g. as an array with two elements). Alternative approach would be not to use this query at all and execute two separate queries where one read product information, while other reads related reviews (probably you would need to use MARS connection in this case). This is not so bad unless if you have a lot of related entities (e.g. product images, product attachments, product categories, etc.) and you need to run several independent queries for a single product.

One of the reasons why NoSQL systems become popular is the fact that you can store composite objects where you can store attributes of primary entity (product in our example) with related records (product reviews) within the primary entity as an array or collection. As an example in MongoDb, DocumentDb you will create one JSON document for Product and add related reviews as an array of JSON objects. You have simpler data model, no JOINs, no additional requests/queries/indexes, all data available in the same record. However, this model is also far from perfect. Although it is good choice for smaller data models, in more complex models you might end-up with heavy objects, or you would need to organize objects in separate collections. In some cases you might need to join objects stored in different collection, and you would find that this is not possible or you need to write complex map/reduce jobs for a simple join.

SQL Server 2016/Azure SQL Database introduce hybrid approach where you can choose between relational model and NoSQL concepts. As an example, if you have products and their reviews you don’t need to create separate tables if you don’t want them. You can create additional columns in the primary table that will contain collection of related entities formatted as JSON arrays. If you already have separate tables and you want to simplify your design, you can add a single column where you can store related reviews:

ALTER TABLE Production.Product
 ADD Reviews NVARCHAR(MAX) 
 CONSTRAINT [Reviews are formatted as JSON] CHECK(ISJSON(Reviews)>0)

In this example, we are adding simple text column with constraint that specifies that reviews should be formatted as JSON (similar to NoSQL databases). There is no new syntax for JSON constraint - you can use standard check constraint with function ISJSON that checks is Reviews text formatted as a JSON object.

If we want to move related product reviews from a separate table into this column we can use a simple UPDATE query:

UPDATE Production.Product
 SET Reviews = (
 SELECT ReviewerName AS [Reviewer.Name],
 EmailAddress AS [Reviewer.E-mail],
 ReviewDate, Rating, Comments AS Comment, ModifiedDate
 FROM Production.ProductReview
 WHERE Production.ProductReview.ProductID = Production.Product.ProductID
 FOR JSON PATH)

Inner query fetches all related reviews, formats them as JSON documents using FOR JSON clause and stores them as JSON text in Reviews column. We can format properties in JSON document using dot syntax (e.g. Product.Name will be created as a Name property in Product object).

Now, we can read products and related reviews with a single query:

SELECT ProductID, Name, Color, ListPrice, Reviews
 FROM Production.Product
 WHERE Reviews IS NOT NULL

Results are shown in the following table:

As you can see, reviews are returned as a collection of JSON objects. There is exactly one row per each product so you do not need any transformation on the client side. This is a perfect choice if your client already expects JSON format for related records (e.g. if you are using some Angular, Knockout or other template engine that injects JSON model into HTML view).

As an alternative if you want to “join” products with related reviews as in the query above, you can use following query:

SELECT ProductID, Name, Color, ListPrice, ReviewerName, ReviewDate, Rating
 FROM Production.Product
 CROSS APPLY OPENJSON(Reviews)
 WITH ( ReviewerName nvarchar(30) '$.Reviewer.Name', 
 ReviewDate datetime2,
 Rating int)
 WHERE Reviews IS NOT NULL

OPENJSON table value function takes related reviews formatted as JSON and returns them as a table. In the WITH part you can specify schema of returned table. Column names match names of the properties in JSON object, and if you have nested property (e.g. Reviewer.Name) you can specify JSON path where this value can be found. CROSS APPLY joins parent row with table returned by OPENJSON functions. Results are shown in the following table:

In both cases you don’t need to scan two tables – all necessary results are taken with a single query.

Summary

Although SQL Server is relational database you don't need to use strict relational theory in you information design. With new JSON support that is coming in SQL Server 2016 and Azure SQL Database you can choose when to follow strict concepts of relational schema design, and when to format objects as in the NoSQL database. SQL Server gives you flexibility to choose the best format for your applications.