Store JSON data in SQL Server 2016

  • Comments posted to this topic are about the item Store JSON data in SQL Server 2016

  • Good question thanks Evgeny.

    ...

  • 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”

  • I'm confused - the MS page you linked in your answer says in its head:
    THIS TOPIC APPLIES TO: yesSQL Server (starting with 2016)

    So why should I not use the JSON datatype?

    God is real, unless declared integer.

  • t.franz - Monday, January 29, 2018 2:08 AM

    I'm confused - the MS page you linked in your answer says in its head:
    THIS TOPIC APPLIES TO: yesSQL 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

    ...

  • t.franz - Monday, January 29, 2018 2:08 AM

    I'm confused - the MS page you linked in your answer says in its head:
    THIS TOPIC APPLIES TO: yesSQL 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.

  • Great question. I didn't know that. Thanks Evgeny

  • 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

  • Eric M Russell - Tuesday, January 30, 2018 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).

    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