

 Amazon Redshift ne prendra plus en charge la création de nouveaux Python à UDFs partir du patch 198. UDFs Le Python existant continuera de fonctionner jusqu'au 30 juin 2026. Pour plus d’informations, consultez le [ billet de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Didacticiel : Faire une requête de données imbriquées avec Amazon Redshift Spectrum
<a name="tutorial-query-nested-data"></a>

Ce didacticiel explique comment interroger des données imbriquées avec Redshift Spectrum. Les données imbriquées sont des données qui contiennent des champs imbriqués. Les champs imbriqués sont des champs assemblés en une seule entité, tels que des tableaux, des structures ou des objets. 

**Topics**
+ [Présentation de](#tutorial-nested-data-overview)
+ [Étape 1 : Création d’un tableau externe contenant des données imbriquées](#tutorial-nested-data-create-table)
+ [Étape 2 : Faire une requête de vos données imbriquées dans Amazon S3 avec des extensions SQL](#tutorial-query-nested-data-sqlextensions)
+ [Cas d’utilisation de données imbriquées](nested-data-use-cases.md)
+ [Limitations des données imbriquées (version préliminaire)](nested-data-restrictions.md)
+ [Sérialisation de JSON imbriqué complexe](serializing-complex-JSON.md)

## Présentation de
<a name="tutorial-nested-data-overview"></a>

Amazon Redshift Spectrum prend en charge la requête de données imbriquées dans Parquet, ORC, JSON et les formats de fichier Ion. Redshift Spectrum accède aux données à l’aide de tableaux externes. Vous pouvez créer des tableaux externes qui utilisent les types de données complexes `struct`, `array`, et `map`.

Par exemple, supposons que votre fichier de données contienne les données suivantes dans Amazon S3 dans un fichier nommé `customers`. Bien qu’il n’y ait aucun élément racine, chaque objet JSON de cet exemple de données représente une ligne d’une table. 

```
{"id": 1,
 "name": {"given": "John", "family": "Smith"},
 "phones": ["123-457789"],
 "orders": [{"shipdate": "2018-03-01T11:59:59.000Z", "price": 100.50},
            {"shipdate": "2018-03-01T09:10:00.000Z", "price": 99.12}]
}
{"id": 2,
 "name": {"given": "Jenny", "family": "Doe"},
 "phones": ["858-8675309", "415-9876543"],
 "orders": []
}
{"id": 3,
 "name": {"given": "Andy", "family": "Jones"},
 "phones": [],
 "orders": [{"shipdate": "2018-03-02T08:02:15.000Z", "price": 13.50}]
}
```

Vous pouvez utiliser Amazon Redshift Spectrum pour soumettre une requête sur les données imbriquées dans des fichiers. Le didacticiel suivant vous montre comment effectuer cette opération avec les données Apache Parquet.

### Conditions préalables
<a name="tutorial-nested-data-prereq"></a>

Si vous n’utilisez pas encore Redshift Spectrum, suivez les étapes détaillées dans [Mise en route avec Amazon Redshift Spectrum](c-getting-started-using-spectrum.md) avant de poursuivre.

Pour créer un schéma externe, remplacez l’ARN de rôle IAM dans la commande suivante par l’ARN de rôle que vous avez créé dans [Créer un rôle IAM](c-getting-started-using-spectrum.md#c-getting-started-using-spectrum-create-role). Ensuite, exécutez la commande dans votre client SQL.

```
create external schema spectrum 
from data catalog 
database 'myspectrum_db' 
iam_role 'arn:aws:iam::123456789012:role/myspectrum_role'
create external database if not exists;
```

## Étape 1 : Création d’un tableau externe contenant des données imbriquées
<a name="tutorial-nested-data-create-table"></a>

Vous pouvez afficher les [données source](https://s3.amazonaws.com/redshift-downloads/tickit/spectrum/customers/customer_file1) en les téléchargeant depuis Amazon S3. 

Exécutez la commande suivante pour créer un tableau externe pour ce didacticiel. 

```
CREATE EXTERNAL TABLE spectrum.customers (
  id     int,
  name   struct<given:varchar(20), family:varchar(20)>,
  phones array<varchar(20)>,
  orders array<struct<shipdate:timestamp, price:double precision>>
)
STORED AS PARQUET
LOCATION 's3://redshift-downloads/tickit/spectrum/customers/';
```

Dans l’exemple précédent, le tableau externe `spectrum.customers` utilise les types de données `struct` et `array` pour définir les colonnes dotées de données imbriquées. Amazon Redshift Spectrum prend en charge la requête de données imbriquées dans Parquet, ORC, JSON et les formats de fichier Ion. Le paramètre `STORED AS` est `PARQUET` pour les fichiers Apache Parquet. Le paramètre `LOCATION` doit se référer au dossier Amazon S3 contenant les données ou fichiers imbriqués. Pour de plus amples informations, veuillez consulter [CREATE EXTERNAL TABLE](r_CREATE_EXTERNAL_TABLE.md).

Vous pouvez imbriquer les types `array` et `struct` à n’importe quel niveau. Vous pouvez par exemple définir une colonne nommée `toparray`, comme l’illustre l’exemple suivant.

```
toparray array<struct<nestedarray:
         array<struct<morenestedarray: 
         array<string>>>>>
```

Vous pouvez également imbriquer les types `struct` comme l’illustre la colonne `x` dans l’exemple suivant.

```
x struct<a: string,
         b: struct<c: integer,
                   d: struct<e: string>
                  >
        >
```

## Étape 2 : Faire une requête de vos données imbriquées dans Amazon S3 avec des extensions SQL
<a name="tutorial-query-nested-data-sqlextensions"></a>

Redshift Spectrum prend en charge les requêtes de types complexes `array`, `map` et `struct` via des extensions à la syntaxe SQL Amazon Redshift. 

### Extension 1 : Accès aux colonnes de structs
<a name="nested-data-sqlextension1"></a>

Vous pouvez extraire des données à partir des colonnes `struct` à l’aide d’une notation par points qui connecte les noms de champs en chemins. Par exemple, la requête suivante retourne les noms et prénoms de clients. Le prénom est obtenu via le long chemin `c.name.given`. Le nom de famille est obtenu via le long chemin `c.name.family`. 

```
SELECT c.id, c.name.given, c.name.family
FROM   spectrum.customers c;
```

La requête précédente renvoie les données suivantes.

```
id | given | family
---|-------|-------
1  | John  | Smith
2  | Jenny | Doe
3  | Andy  | Jones
(3 rows)
```

Un `struct` peut être une colonne d’un autre `struct`, qui peut être une colonne d’un autre `struct` et ce à tout niveau. Les chemins qui accèdent aux colonnes dans des `struct` aussi profondément imbriqués peuvent être très longs. Par exemple, regardez la définition pour la colonne `x` dans l’illustration suivante.

```
x struct<a: string,
         b: struct<c: integer, 
                      d: struct<e: string>
                  >
        >
```

Vous pouvez accéder aux données dans `e` en tant que `x.b.d.e`.

### Extension 2 : Surplomber les pans d’une clause FROM
<a name="nested-data-sqlextension2"></a>

Vous pouvez extraire des données de colonnes `array` (et, par extension, des colonnes `map`) en précisant les colonnes `array` dans une clause `FROM` à la place des noms de tableaux. L’extension s’applique à la clause `FROM` de la requête principale, ainsi qu’aux clauses `FROM` des sous-requêtes.

Vous pouvez référencer les éléments `array` d’après leur position, comme `c.orders[0]` (version préliminaire).

En combinant le surplombage de `arrays` avec des raccords, vous pouvez réaliser différentes sortes de désimbrication, comme les cas d’utilisation suivants l’expliquent. 

#### Désimbrication à l’aide de raccords internes
<a name="unnest-inner-joins"></a>

La requête suivante sélectionne les dates d'expédition IDs des clients et des commandes pour les clients qui ont des commandes. L’extension SQL dans la clause FROM `c.orders o` dépend de l’alias `c`.

```
SELECT c.id, o.shipdate
FROM   spectrum.customers c, c.orders o
```

Pour chaque `c` de client disposant de commandes, la clause `FROM` renvoie une ligne pour chaque commande `o` du client `c`. Cette ligne combine la ligne du client `c` et la ligne de commande `o`. Ensuite, la clause `SELECT` garde uniquement le `c.id` et le `o.shipdate`. Le résultat est le suivant.

```
id|      shipdate
--|----------------------
1 |2018-03-01  11:59:59
1 |2018-03-01  09:10:00
3 |2018-03-02  08:02:15
(3 rows)
```

L’alias `c` fournit un accès aux champs du client et l’alias `o` fournit un accès aux champs de commande. 

La sémantique est similaire au SQL standard. Vous pouvez envisager la clause `FROM` comme exécutant la boucle imbriquée suivante qui est suivie par la sélection de champs pour la sortie par `SELECT`. 

```
for each customer c in spectrum.customers
  for each order o in c.orders
     output c.id and o.shipdate
```

Ainsi, si un client ne dispose pas de commande, le client n’apparaît pas dans le résultat.

Vous pouvez également envisager ceci comme une clause `FROM` qui exécute un `JOIN` avec le tableau `customers` et le pan `orders`. Dans les faits, vous pouvez également rédiger la requête comme l’illustre l’exemple suivant.

```
SELECT c.id, o.shipdate
FROM   spectrum.customers c INNER JOIN c.orders o ON true
```

**Note**  
Si un schéma nommé `c` existe avec un tableau nommé `orders`, alors `c.orders` se réfère au tableau `orders`, et non à la colonne de pan `customers`.

#### Désimbrication à l’aide de raccords gauches
<a name="unnest-left-joins"></a>

La requête suivante sort tous les noms des clients et leurs commandes. Si un client n’a pas encore placé de commande, son nom sera tout de même renvoyé. Cependant, dans ce cas, les colonnes de commande sont NULLES, comme l’illustre l’exemple suivant pour Jenny Doe.

```
SELECT c.id, c.name.given, c.name.family, o.shipdate, o.price
FROM   spectrum.customers c LEFT JOIN c.orders o ON true
```

La requête précédente renvoie les données suivantes.

```
id  |  given  | family  |    shipdate          | price
----|---------|---------|----------------------|--------
 1  |  John   | Smith   | 2018-03-01  11:59:59 | 100.5
 1  |  John   | Smith   | 2018-03-01  09:10:00 |  99.12
 2  |  Jenny  | Doe     |                      |
 3  |  Andy   | Jones   | 2018-03-02  08:02:15 |  13.5
 (4 rows)
```

### Extension 3 : Obtenir directement à un pan de scalaires en utilisant un alias
<a name="nested-data-sqlextension3"></a>

Lorsqu’un alias `p` dans une clause `FROM` surplombe tout un tableau de scalaires, la requête se réfère aux valeurs de `p` en tant que `p`. Par exemple, la requête suivante produit des paires de noms de clients et de numéros de téléphone.

```
SELECT c.name.given, c.name.family, p AS phone
FROM   spectrum.customers c LEFT JOIN c.phones p ON true
```

La requête précédente renvoie les données suivantes.

```
given  |  family  |  phone
-------|----------|-----------
John   | Smith    | 123-4577891
Jenny  | Doe      | 858-8675309
Jenny  | Doe      | 415-9876543
Andy   | Jones    | 
(4 rows)
```

### Extension 4 : Accès aux éléments de cartes
<a name="nested-data-sqlextension4"></a>

Redshift Spectrum traite le type de donnée `map` comme un type de `array` contenant des types `struct` avec une colonne `key` et une colonne `value`. La `key` doit être `scalar`; la valeur peut être de n’importe quel type de donnée. 

Par exemple, le code suivant crée un tableau externe avec une `map` pour stocker les numéros de téléphone.

```
CREATE EXTERNAL TABLE spectrum.customers2 (
  id     int,
  name   struct<given:varchar(20), family:varchar(20)>,
  phones map<varchar(20), varchar(20)>,
  orders array<struct<shipdate:timestamp, price:double precision>>
)
STORED AS PARQUET
LOCATION 's3://redshift-downloads/tickit/spectrum/customers/';
```

Parce qu’un type de `map` se comporte comme un type de `array` avec des colonnes `key` et `value`, vous pouvez penser aux schémas précédents comme s’ils étaient les suivants.

```
CREATE EXTERNAL TABLE spectrum.customers3 (
  id     int,
  name   struct<given:varchar(20), family:varchar(20)>,
  phones array<struct<key:varchar(20), value:varchar(20)>>,
  orders array<struct<shipdate:timestamp, price:double precision>>
)
STORED AS PARQUET
LOCATION 's3://redshift-downloads/tickit/spectrum/customers/';
```

La requête suivante renvoie les noms de clients avec un numéro de téléphone mobile et renvoie le numéro pour chaque nom. La requête de carte est traitée comme l’équivalent d’une requête de `array` imbriquée de types `struct`. La requête suivante ne renvoie des données que si vous avez créé le tableau externe précédemment évoqué. 

```
SELECT c.name.given, c.name.family, p.value 
FROM   spectrum.customers c, c.phones p 
WHERE  p.key = 'mobile';
```

**Note**  
La `key` pour une `map` est une `string` pour les types de fichiers Ion et JSON.

# Cas d’utilisation de données imbriquées
<a name="nested-data-use-cases"></a>

Cette rubrique décrit les cas d’utilisation des données imbriquées. Les données imbriquées sont des données qui contiennent des champs imbriqués. Les champs imbriqués sont des champs assemblés en une seule entité, tels que des tableaux, des structures ou des objets. 

Vous pouvez combiner les extensions précédemment décrites avec les caractéristiques SQL habituelles. Les cas d’utilisation suivants illustrent certaines combinaisons courantes. Ces exemples aident à illustrer comment utiliser des données imbriquées. Elles ne font pas partie du didacticiel.

**Topics**
+ [Ingérer des données imbriquées](#ingesting-nested-data)
+ [Agréger des données imbriquées avec des sous-requêtes](#aggregating-with-subquery)
+ [Joindre Amazon Redshift et des données imbriquées](#joining-redshift-data)

## Ingérer des données imbriquées
<a name="ingesting-nested-data"></a>

Vous pouvez utiliser une déclaration `CREATE TABLE AS` pour ingérer des données à partir d’un tableau externe contenant des types de données complexes. La requête suivante extrait tous les clients et leurs numéros de téléphone à partir du tableau externe, à l’aide de `LEFT JOIN` et les stocke dans le tableau Amazon Redshift `CustomerPhones`. 

```
CREATE TABLE CustomerPhones AS
SELECT  c.name.given, c.name.family, p AS phone
FROM    spectrum.customers c LEFT JOIN c.phones p ON true;
```

## Agréger des données imbriquées avec des sous-requêtes
<a name="aggregating-with-subquery"></a>

Vous pouvez utiliser une sous-requête pour agréger des données imbriquées. L’exemple suivant illustre cette approche. 

```
SELECT c.name.given, c.name.family, (SELECT COUNT(*) FROM c.orders o) AS ordercount 
FROM   spectrum.customers c;
```

Les données suivantes sont renvoyées.

```
given   |  family  |  ordercount
--------|----------|--------------
 Jenny  |  Doe     |       0
 John   |  Smith   |       2
 Andy   |  Jones   |       1
 (3 rows)
```

**Note**  
La manière la plus efficace d’agréger des données imbriquées en les groupant par ligne parent est illustrée dans l’exemple précédent. Dans cet exemple, les lignes imbriquées de `c.orders` sont groupées par leur ligne parent `c`. Autrement, si vous savez que l’`id` est unique pour chaque `customer` et que `o.shipdate` n’a jamais une valeur nulle, vous pouvez agréger de la manière illustrée dans l’exemple suivant. Cependant, cette approche n’est généralement pas aussi efficace que l’exemple précédent. 

```
SELECT    c.name.given, c.name.family, COUNT(o.shipdate) AS ordercount 
FROM      spectrum.customers c LEFT JOIN c.orders o ON true 
GROUP BY  c.id, c.name.given, c.name.family;
```

Vous pouvez également rédiger la requête en utilisant une sous-requête dans la clause `FROM` qui se réfère à un alias (`c`) de la requête d’ancêtre et extrait les données de tableau. L’exemple suivant illustre cette approche.

```
SELECT c.name.given, c.name.family, s.count AS ordercount
FROM   spectrum.customers c, (SELECT count(*) AS count FROM c.orders o) s;
```

## Joindre Amazon Redshift et des données imbriquées
<a name="joining-redshift-data"></a>

Vous pouvez également raccorder les données Amazon Redshift aux données imbriquées dans un tableau externe. Par exemple, supposons que vous avez les données imbriquées suivantes dans Amazon S3. 

```
CREATE EXTERNAL TABLE spectrum.customers2 (
  id      int,
  name    struct<given:varchar(20), family:varchar(20)>,
  phones  array<varchar(20)>,
  orders  array<struct<shipdate:timestamp, item:int>>
);
```

Supposons également que vous disposez du tableau suivant dans Amazon Redshift.

```
CREATE TABLE prices (
  id int,
  price double precision
);
```

La requête suivante trouve le nombre total et le montant de chaque achat du client selon ce qui précède. L’illustration suivante n’est qu’un exemple. Elle ne renvoie des données que si vous avez créé les tableaux précédemment évoqués. 

```
SELECT   c.name.given, c.name.family, COUNT(o.date) AS ordercount, SUM(p.price) AS ordersum 
FROM     spectrum.customers2 c, c.orders o, prices p ON o.item = p.id  
GROUP BY c.id, c.name.given, c.name.family;
```

# Limitations des données imbriquées (version préliminaire)
<a name="nested-data-restrictions"></a>

Cette rubrique décrit les limitations liées à la lecture de données imbriquées avec Redshift Spectrum. Les données imbriquées sont des données qui contiennent des champs imbriqués. Les champs imbriqués sont des champs assemblés en une seule entité, tels que des tableaux, des structures ou des objets. 

**Note**  
Les limitations marquées (version préliminaire) dans la liste suivante s’appliquent uniquement aux clusters en version préliminaire créés dans les régions suivantes.  
USA Est (Ohio) (us-east-2)
USA Est (Virginie du Nord) (us-east-1)
USA Ouest (Californie du Nord) (us-west-1)
Asie-Pacifique (Tokyo) (ap-northeast-1)
Europe (Irlande) (eu-west-1)
Europe (Stockholm) (eu-north-1)
Pour en savoir plus sur la configuration des clusters en version préliminaire, consultez [Création d’un cluster en version préliminaire](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-console.html#cluster-preview) dans le *Guide de gestion Amazon Redshift*. 

Les limites suivantes s’appliquent aux données imbriquées :
+ Un type `array` ou `map` peut contenir d’autres types `array` ou `map` tant que les requêtes sur les types imbriqués `arrays` ou `maps` ne renvoient pas de valeurs `scalar` (version préliminaire). 
+ Amazon Redshift Spectrum prend uniquement en charge les types de données complexes sous forme de tables externes.
+  Les colonnes de résultats des sous-requêtes doivent être de niveau supérieur (version préliminaire).
+ Si une expression `OUTER JOIN` se réfère à un tableau imbriqué, il ne peut que se référer à ce tableau et ses pans imbriqués (et ses cartes). Si une expression `OUTER JOIN` ne se réfère pas à un tableau imbriqué, il peut se référer à tout genre de tableaux non imbriqués.
+ Si une clause `FROM` d’une sous-requête se réfère à un tableau imbriqué, il ne peut se référer à quelconque autre tableau.
+ Si une sous-requête dépend d’une table imbriquée qui se réfère à un parent, vous ne pouvez utiliser le parent que dans la clause `FROM`. Vous ne pouvez pas utiliser le parent dans une quelconque autre clause, comme une clause `SELECT` ou `WHERE`. Par exemple, la requête suivante ne s’exécute pas, car la clause `SELECT` de la sous-requête fait référence à la table parent `c`. 

  ```
  SELECT c.name.given 
  FROM   spectrum.customers c 
  WHERE (SELECT COUNT(c.id) FROM c.phones p WHERE p LIKE '858%') > 1;
  ```

  La requête suivante fonctionne parce que le parent `c` est utilisé uniquement dans la clause `FROM` de la sous-requête.

  ```
  SELECT c.name.given 
  FROM   spectrum.customers c 
  WHERE (SELECT COUNT(*) FROM c.phones p WHERE p LIKE '858%') > 1;
  ```
+ Une sous-requête qui accède à des données imbriquées à tout autre endroit que la clause `FROM` doit renvoyer une seule valeur. Les seules exceptions sont les opérateurs `(NOT) EXISTS` dans une clause `WHERE`.
+ `(NOT) IN` n’est pas pris en charge.
+ La profondeur d’imbrication maximum pour tous les types imbriqués est de 100. Cette restriction s’applique à tous les formats de fichier (Parquet, ORC, Ion et JSON).
+ Les sous-requêtes d’agrégation qui accèdent aux données imbriquées peuvent uniquement se reporter à `arrays` et `maps` dans leur clause `FROM`, et non pas à une table externe. 
+ L’interrogation des pseudocolonnes de données imbriquées dans une table Redshift Spectrum n’est pas prise en charge. Pour de plus amples informations, veuillez consulter [Pseudocolonnes](c-spectrum-external-tables.md#c-spectrum-external-tables-pseudocolumns). 
+ Quand vous extrayez des données à partir de colonnes d’un tableau ou d’une carte en les spécifiant dans une clause `FROM`, vous ne pouvez sélectionner des valeurs dans ces colonnes que si les valeurs sont `scalar`. Par exemple, les requêtes suivantes essayent toutes deux de sélectionner (`SELECT`) des éléments depuis l’intérieur d’un tableau. La requête qui sélectionne fonctionne `arr.a`, car `arr.a` est une valeur `scalar`. La deuxième requête ne fonctionne pas, car `array` est un tableau extrait de `s3.nested table` dans la clause `FROM` (version préliminaire).

  ```
  SELECT array_column FROM s3.nested_table;
  
  array_column
  -----------------
  [{"a":1},{"b":2}]
                          
  SELECT arr.a FROM s3.nested_table t, t.array_column arr;
  
  arr.a
  -----
  1
  
  --This query fails to run.
  SELECT array FROM s3.nested_table tab, tab.array_column array;
  ```

  Vous ne pouvez pas utiliser dans la clause `FROM` un tableau ni une carte qui proviennent eux-mêmes d’un autre tableau ou d’une autre carte. Pour sélectionner des tableaux ou d’autres structures complexes imbriquées dans d’autres tableaux, pensez à utiliser des index dans l’instruction `SELECT`.

# Sérialisation de JSON imbriqué complexe
<a name="serializing-complex-JSON"></a>

Cette rubrique explique comment sérialiser les données imbriquées au format JSON. Les données imbriquées sont des données qui contiennent des champs imbriqués. Les champs imbriqués sont des champs assemblés en une seule entité, tels que des tableaux, des structures ou des objets. 

Une alternative aux méthodes présentées dans ce didacticiel consiste à interroger les colonnes de collection imbriquées de niveau supérieur en tant que JSON sérialisé. Vous pouvez utiliser la sérialisation pour inspecter, convertir et intégrer des données imbriquées au format JSON avec Redshift Spectrum. Cette méthode est prise en charge pour les formats ORC, JSON, Ion et Parquet. Utilisez le paramètre de configuration de session `json_serialization_enable` pour configurer le comportement de sérialisation. Lorsqu’ils sont définis, les types de données JSON complexes sont sérialisés en VARCHAR (65535). Le JSON imbriqué est accessible avec les [Fonctions JSON](json-functions.md). Pour de plus amples informations, veuillez consulter [json\$1serialization\$1enable](r_json_serialization_enable.md).

Par exemple, sans définir `json_serialization_enable`, les requêtes suivantes qui accèdent directement aux colonnes imbriquées échouent. 

```
SELECT * FROM spectrum.customers LIMIT 1;

=> ERROR:  Nested tables do not support '*' in the SELECT clause.

SELECT name FROM spectrum.customers LIMIT 1;

=> ERROR:  column "name" does not exist in customers
```

Le paramètre `json_serialization_enable` permet d’interroger directement les collections de niveau supérieur. 

```
SET json_serialization_enable TO true;

SELECT * FROM spectrum.customers order by id LIMIT 1;

id | name                                 | phones         | orders
---+--------------------------------------+----------------+----------------------------------------------------------------------------------------------------------------------
1  | {"given": "John", "family": "Smith"} | ["123-457789"] | [{"shipdate": "2018-03-01T11:59:59.000Z", "price": 100.50}, {"shipdate": "2018-03-01T09:10:00.000Z", "price": 99.12}]          
 
SELECT name FROM spectrum.customers order by id LIMIT 1;

name
---------
{"given": "John", "family": "Smith"}
```

Tenez compte des éléments suivants lors de la sérialisation du JSON imbriqué.
+ Lorsque les colonnes de collection sont sérialisées en tant que VARCHAR(65535), leurs sous-champs imbriqués ne sont pas accessibles directement dans le cadre de la syntaxe de requête (par exemple, dans la clause de filtre). Cependant, les fonctions JSON peuvent être utilisées pour accéder au JSON imbriqué. 
+ Les représentations spécialisées suivantes ne sont pas prises en charge : 
  + Syndicats ORC
  + Cartes ORC avec clés de type complexe
  + Datagrammes Ion
  + SEXP Ion
+ Les horodatages sont renvoyés sous forme de chaînes sérialisées ISO.
+ Les clés de carte primitives sont promues en chaîne (par exemple, `1` sur `"1"`).
+ Les valeurs nulles de niveau supérieur sont sérialisées sous la forme. NULLs
+ Si la sérialisation dépasse la taille VARCHAR maximale de 65535, la cellule est définie sur NULL.

## Sérialisation de types complexes contenant des chaînes JSON
<a name="serializing-complex-JSON-strings"></a>

Par défaut, les valeurs de chaîne contenues dans les collections imbriquées sont sérialisées en tant que chaînes JSON échappées. L’échappement peut être problématique lorsque les chaînes sont JSON valides. Au lieu de cela, vous pouvez écrire des sous-éléments ou des champs imbriqués VARCHAR directement en tant que JSON. Activez ce comportement avec la configuration au niveau de la session `json_serialization_parse_nested_strings`. Lorsque `json_serialization_enable` et `json_serialization_parse_nested_strings` sont définis, les valeurs JSON valides sont sérialisées en ligne sans caractères d’échappement. Lorsque la valeur n’est pas un JSON valide, elle est échappée comme si la valeur de configuration `json_serialization_parse_nested_strings` n’était pas définie. Pour de plus amples informations, veuillez consulter [json\$1serialization\$1parse\$1nested\$1strings](r_json_serialization_parse_nested_strings.md).

Supposons que les données de l’exemple précédent contiennent JSON en tant que type complexe `structs` dans le champ `name` VARCHAR(20) : 

```
name
---------
{"given": "{\"first\":\"John\",\"middle\":\"James\"}", "family": "Smith"}
```

Lorsque `json_serialization_parse_nested_strings` est défini, la colonne `name` est sérialisée comme suit : 

```
SET json_serialization_enable TO true;
SET json_serialization_parse_nested_strings TO true;
SELECT name FROM spectrum.customers order by id LIMIT 1;

name
---------
{"given": {"first":"John","middle":"James"}, "family": "Smith"}
```

Au lieu d’être échappée comme suit :

```
SET json_serialization_enable TO true;
SELECT name FROM spectrum.customers order by id LIMIT 1;

name
---------
{"given": "{\"first\":\"John\",\"middle\":\"James\"}", "family": "Smith"}
```