January 28, 2018 at 12:02 am
Comments posted to this topic are about the item Store JSON data in SQL Server 2016
January 28, 2018 at 12:03 am
Good question thanks Evgeny.
...
January 28, 2018 at 10:11 pm
Nice question to start the week on, thanks Evgeny
____________________________________________
Space, the final frontier? not any more...
All limits henceforth are self-imposed.
“libera tute vulgaris ex”
January 29, 2018 at 3:50 am
t.franz - Monday, January 29, 2018 2:08 AMI'm confused - the MS page you linked in your answer says in its head:
THIS TOPIC APPLIES TO: SQL Server (starting with 2016)So why should I not use the JSON datatype?
There is no JSON data type in SQL2016, I understand the idea was bounced for reasons of customer convenience although I cannot find the link at the moment...or perhaps I can as on here
...
January 29, 2018 at 6:49 am
t.franz - Monday, January 29, 2018 2:08 AMI'm confused - the MS page you linked in your answer says in its head:
THIS TOPIC APPLIES TO: SQL Server (starting with 2016)So why should I not use the JSON datatype?
The page describes how to process JSON data using the built-in functions that are available in SQL Server 2016. However, there is no JSON datatype as such. As the examples show, the JSON text itself is stored in NVARCHAR(MAX) columns in the tables.
Hope that helps.
January 30, 2018 at 7:49 am
Great question. I didn't know that. Thanks Evgeny
January 30, 2018 at 8:30 am
As a side note, if what you really need to do is store a collection of JSON documents and work with the data natively as a JSON objects, arrays, properties, etc., then consider DocumentDB (Microsoft Cosmos DB).
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 19, 2019 at 12:34 pm
Eric M Russell - Tuesday, January 30, 2018 8:30 AMAs a side note, if what you really need to do is store a collection of JSON documents and work with the data natively as a JSON objects, arrays, properties, etc., then consider DocumentDB (Microsoft Cosmos DB).
Just be aware that the charges for DocumentDB (Azure) are probably more than they are for SQL. I tried some of the document stuff on Azure and it was very expensive for whatever reason.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply