![\"REST](\"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-content\/uploads\/sites\/56\/2020\/07\/image-01-1024x802.png\")
<\/p>\n<\/p>\n
Azure SQL has native JSON<\/a>\u00a0support which is a key factor to simplify a lot \u2014 and make developer-friendly \u2014 the interaction between the database and any service that needs to handle data in even the most exotic way.<\/p>\n As depicted in the image above, JSON can be passed as-is and with just one line of code can be sent to Azure SQL where it can processed and returned in a JSON format. I\u2019m using Python in this sample but really, no matter which language you are using for your project, the workflow is the same. And the result is that, as a developer, you won\u2019t see any recordset or anything that resemble a tabular structure in any way. Just JSON, that can easily be serialized and de-serialized into an object for maximum convenience and easiness of development. Or just kept as a JSON document if you prefer.<\/p>\n All the heavy lifting, in fact, is done by Azure SQL for you thanks to functions like\u00a0JSON_VALUE<\/a>\u00a0and\u00a0FOR JSON<\/a>.<\/p>\n To make things even easier, Python has an amazing framework named Flask that make the creation of REST API pretty simple. But there\u2019s even more. Flask has an extension on its own to make that process even easier. You just have to create your class with a method for each verb you wan to support. Impressive, really. Here\u2019s the two libraries you have to use:<\/p>\n You can find a full explanation along with the source code (hosted on GitHub) and al the details to deploy the solution in Azure. You\u2019ll be able to create and deploy your API in less than 5 minutes!<\/p>\n Building REST API with Python, Flask and Azure SQL<\/a><\/p>\n Interesting question. Answer is\u2026easy. Yeah, you didn\u2019t expect that right? Here it is: if you need to store JSON as is, with no or really minimal need to query data stored therein and no need to make complex partial updates to the stored documents, then a document database could be a great choice. If you need anything else, like ability to execute non-trivial queries on data, process aggregates, have transaction consistency, fine-grained security and the need to validate ingested data against a schema, then a relational database should be your choice.<\/p>\n If you\u2019re thinking that you don\u2019t need a schema (and this is the main reason why you\u2019re choosing a NoSQL database), since something like a \u201cschema-less\u201d is a better choice as it will give your much more flexibility and freedom, well\u2026.go and read this:<\/p>\n Schemaless Data Structures<\/a><\/p>\n The entire schema-less idea is like a\u00a0Leprechaun<\/a><\/em>. No, it won\u2019t give you the gold at the end of the rainbow: it just doesn\u2019t exists!<\/p><\/blockquote>\n By using Azure SQL you have even more reasons why you\u00a0should <\/strong>use it: it is a modern, scalable, (post-)relational database, where you can find an amazing number of features that you\u2019ll need to find somewhere else otherwise. This would mean to use many different data management solution (Document, Graph, Key-Value store)\u2026and then having to deal with one of the most difficult problem to solve. Data Integration. If it is absolutely true that Naming Things and Cache Invalidation are the two hardest problem in Computer Science:<\/p>\n![\"JSON](\"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-content\/uploads\/sites\/56\/2020\/07\/image-02-1024x434.png\")
<\/p>\nWhy I should use a Relational Database at all?<\/h2>\n