Sqlserver
 sql >> база данни >  >> RDS >> Sqlserver

JSON_QUERY() Примери в SQL Server (T-SQL)

Когато използвате JSON със SQL Server, можете да използвате JSON_QUERY() функция за извличане на обект или масив от JSON низ.

За да използвате тази функция, предоставяте израза JSON като аргумент. Можете също да предоставите втори (по избор) аргумент, за да посочите обекта или масива за извличане.

Синтаксис

Синтаксисът е така:

JSON_QUERY (израз [, път]) 

Където expression е низовият израз на JSON и path е обектът или масивът, който искате да извлечете от този израз. path аргументът не е задължителен (ако не го предоставите, се връща целият JSON документ).

Аргументът на пътя (ако е предоставен) може да включва незадължителен режим на път съставна част. Този незадължителен режим на пътя може да бъде стойност на lax или strict . Тази стойност определя какво се случва в случай, че предоставеният път е невалиден. Режимът на пътя (ако е предоставен) идва преди знака за долар.

Пример 1 – Основна употреба

Ето пример за демонстриране на основното използване на JSON_QUERY() функция.

DECLARE @data NVARCHAR(4000)SET @data=N'{ "Cities":[ { "Name":"Kabul", "CountryCode":"AFG", "District":"Kabol", "Population" :1780000 }, { "Име":"Кандахар", "Код на страната":"AFG", "Округ":"Кандахар", "Население":237500 } ]}'SELECT JSON_QUERY(@data, '$.Cities[0 ]') КАТО 'Резултат';

Резултат:

+---------+| Резултат ||----------|| { "Име":"Кабул", "Код на страната":"AFG", "Округ":"Кабол", "Население":1780000 } |+----------+

В този пример първо декларирам и задам променлива, наречена @data . След това присвоявам масив към тази променлива. След като направя това, изпълнявам заявка към този масив.

В този случай използвам Cities[0] за препратка към първия елемент в масива (JSON масивите използват номериране на база нула).

Мога да осъществя достъп до втория елемент, като използвам Cities[1] . Като това:

DECLARE @data NVARCHAR(4000)SET @data=N'{ "Cities":[ { "Name":"Kabul", "CountryCode":"AFG", "District":"Kabol", "Population" :1780000 }, { "Име":"Кандахар", "Код на страната":"AFG", "Округ":"Кандахар", "Население":237500 } ]}'SELECT JSON_QUERY(@data, '$.Cities[1 ]') КАТО 'Резултат';

Резултат:

+---------+| Резултат ||----------|| { "Име":"Кандахар", "Код на страната":"AFG", "Округ":"Кандахар", "Население":237500 } |+----------+

Пример 2 – Връщане на целия JSON израз

Вторият аргумент е незадължителен, така че ако го пропуснете, се връща целият JSON документ. Ето какво се случва, когато направим това, използвайки същите данни от предишните примери:

DECLARE @data NVARCHAR(4000)SET @data=N'{ "Cities":[ { "Name":"Kabul", "CountryCode":"AFG", "District":"Kabol", "Population" :1780000 }, { "Име":"Кандахар", "Код на страната":"AFG", "Окръг":"Кандахар", "Население":237500 } ]}'ИЗБЕРЕТЕ JSON_QUERY(@data) КАТО 'Резултат'; 

Резултат:

+---------+| Резултат ||----------|| { "Градове":[ { "Име":"Кабул", "Код на страната":"AFG", "Округ":"Кабол", "Население":1780000 }, { "Име":"Кандахар", "Код на страната" :"AFG", "District":"Qandahar", "Население":237500 } ]} |+----------+

Пример 3 – Пример за база данни

Ако трябваше да поставим данните от предишния пример в база данни, бихме могли да пренапишем заявката, както следва:

ИЗБЕРЕТЕ JSON_QUERY(Document,'$.Cities[0]') КАТО 'Град 1'ОТ Json_Documents

Резултат:

+---------+| Град 1 ||----------|| { "ID":1, "Име":"Кабул", "Код на държава":"AFG", "Округ":"Кабол", "Население":1780000 } |+----------+ 

Това предполага, че JSON документът се съхранява в колона, наречена Document , който е в таблица, наречена Json_Documents .

Пример 4 – Скаларни стойности

JSON_QUERY() функцията не е предназначена да връща скаларни стойности. Ако искате да върнете скаларна стойност, използвайте JSON_VALUE() функция вместо това.

Въпреки това, нищо не ви пречи да комбинирате и двете функции в рамките на заявка, за да върнете данни на различни нива на детайлност.

Ето един пример:

DECLARE @data NVARCHAR(4000)SET @data=N'{ "Sospect":{ "Име":"Хоумър Симпсън", "Хобита":["Хранене", "Спане", "Скачане на бейсбол"] } }' SELECT JSON_VALUE(@data,'$.Suspect.Name') КАТО 'Име', JSON_QUERY(@data,'$.Suspect.Hobbies') КАТО 'Хобита', JSON_VALUE(@data,'$.Suspect.Hobbies [2]') КАТО 'Последно хоби';

Резултат:

+---------------+------------------------------ ----------+--------------+| Име | Хобита | Последно хоби ||--------------+------------------------------ ----------+--------------|| Хоумър Симпсън | ["Хранене", "Спане", "Скачане на бейсбол"] | Бейс скокове |+--------------+------------------------------ ----------+--------------+

В този пример използвах JSON_VALUE() за извличане на различни скаларни стойности, но използвах и JSON_QUERY() за да върне цял масив (който JSON_VALUE() не мога да направя).

Пример 5 – Режим на пътя

Както споменахме, вие също имате възможност да посочите режима на пътя. Това може да бъде или lax или strict .

Стойността на режима на пътя определя какво се случва, когато изразът за път съдържа грешка. По-конкретно:

  • В слабо режим, функцията връща празни стойности, ако изразът за път съдържа грешка. Например, ако поискате стойността $.name , а JSON текстът не съдържа име ключ, функцията връща null, но не предизвиква грешка.
  • В строго режим, функцията повдига грешка, ако изразът за пътя съдържа грешка.

Стойността по подразбиране е lax .

Ето пример за демонстриране на разликата между тези два режима.

Грешка в слаб режим

Ето какво се случва, когато изразът за път съдържа грешка, докато е в слаб режим.

SELECT JSON_QUERY('{"Име":"Брус"}', 'lax $.Name') КАТО 'Резултат';

Резултат:

+---------+| Резултат ||----------|| NULL |+----------+

В този пример се опитваме да върнем скаларна стойност, но JSON_QUERY() не прави скаларни стойности. Както споменахме, той връща само обекти и масиви. В този случай получаваме нулева стойност (защото използваме слаб режим).

Грешка в строг режим

Ето какво се случва, когато изпълним същия код в строг режим.

SELECT JSON_QUERY('{"Име":"Брус"}', 'строго $.Name') КАТО 'Резултат';

Резултат:

Съобщение 13624, ниво 16, състояние 2, ред 1 Обектът или масивът не могат да бъдат намерени в посочения JSON път.

Както се очакваше, строг режим води до съобщение за грешка, обясняващо грешката.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. SQL грешка:Неправилен синтаксис близо до ключовата дума „Потребител“

  2. Поддържа ли интеграцията на SQL Server CLR конфигурационни файлове?

  3. С ПРОВЕРКА НА ДОБАВЯНЕ НА ОГРАНИЧЕНИЕ, последвано от ПРОВЕРКА НА ОГРАНИЧЕНИЕ спрямо ДОБАВЯНЕ НА ОГРАНИЧЕНИЕ

  4. Къдрави скоби в T-SQL

  5. Примери за преобразуване на „дата“ в „datetimeoffset“ в SQL Server (T-SQL)