J'ai remarqué que les valeurs-clés peuvent ne pas être citées lorsqu'elles sont numériques dans les chaînes TSQL JSON, mais il semble que le composant clé doit toujours être cité.
select 1, isjson(''), 'empty string' union
select 2, isjson('{}'), 'empty braces' union
select 3, isjson('{1:2}'), 'unquoted both, numerals both' union
select 4, isjson('{1:"2"}'), 'unquoted key, numerals both' union
select 5, isjson('{"1":2}'), 'unquoted value, numerals both' union
select 6, isjson('{"1":"2"}'), 'quoted both, numerals both' union
select 7, isjson('{a:b}'), 'unquoted both, alpha both' union
select 8, isjson('{a:"b"}'), 'unquoted key, alpha both' union
select 9, isjson('{"a":b}'), 'unquoted value, alpha both' union
select 10, isjson('{"a":"b"}'), 'quoted both, alpha both'
order by 1
;
Résultats:
1 0 empty string
2 1 empty braces
3 0 unquoted both, numerals both
4 0 unquoted key, numerals both
5 1 unquoted value, numerals both
6 1 quoted both, numerals both
7 0 unquoted both, alpha both
8 0 unquoted key, alpha both
9 0 unquoted value, alpha both
10 1 quoted both, alpha both
Ce qui précède le démontre, mais mes questions sont les suivantes:
La définition de notation JSON suit le schéma suivant:
La définition de la chaîne est la suivante:
Vous pouvez voir que les guillemets sont obligatoires au début et à la fin.
La définition de la valeur est la suivante:
Notez qu'ici, vous pouvez fournir une chaîne ou un nombre , le nombre étant:
Conclusions :
Je ne peux pas expliquer pourquoi JSON a adopté ce schéma particulier et une réponse ici pourrait être basée sur une opinion.
SQL Server obtiendra toujours une augmentation des performances lors du traitement des entiers sur les types de données de chaîne (comme VARCHAR
ou NVARCHAR
) car ils sont plus rapides à utiliser et à comparer, mais assurez-vous que le type de données est en fait un type numérique et non un nombre stocké sous forme de chaîne.