Types de données compatibles avec l'ancien SQL

Ce document détaille les types de données compatibles avec l'ancien SQL, la syntaxe de requête de BigQuery. La syntaxe de requête privilégiée pour BigQuery est le langage SQL standard. Pour en savoir plus sur les types de données du langage SQL standard, consultez la page Types de données du langage SQL standard.

Types de données compatibles avec l'ancien SQL

Vos données peuvent inclure les types de données suivants :

Type de données Valeurs possibles
STRING Données de type caractères de longueur variable (UTF-8).
BYTES Données binaires de longueur variable.
  • Les données BYTES importées doivent être encodées en base64, à l'exception des données BYTES Avro que BigQuery peut lire et convertir.
  • Les données BYTES lues depuis une table BigQuery sont encodées en base64, à moins que vous ne les exportiez au format Avro, auquel cas le type de données bytes Avro s'applique.
INTEGER

Entier signé de 64 bits.

Si vous utilisez l'API BigQuery pour charger un entier situé en dehors de la plage [-253+1, 253-1] (dans la plupart des cas, cela signifie supérieur à 9 007 199 254 740 991), dans une colonne d'entiers (INT64), vous devez la transmettre en tant que chaîne pour éviter toute corruption des données. Ce problème est causé par une limite de taille d'entier dans JSON/ECMAScript. Pour en savoir plus, consultez la section Nombre de la RFC 7159.

FLOAT Format à virgule flottante avec deux décimales.
NUMERIC L'ancien SQL est compatible de façon limitée avec les données de type NUMERIC. Pour en savoir plus, consultez la section Valeurs NUMERIC en ancien SQL.
BOOLÉN
  • Format CSV : 1 ou 0, true ou false, t ou f, yes ou no, ou y ou n (tous non sensibles à la casse).
  • Format JSON : true ou false (non sensibles à la casse).
RECORD Collection d'un ou de plusieurs autres champs.
TIMESTAMP

Vous pouvez décrire les données de type TIMESTAMP comme étant des horodatages UNIX, ou des dates et heures de calendrier. BigQuery stocke les données TIMESTAMP en interne sous la forme d'un horodatage UNIX avec une précision de l'ordre de la microseconde.

Horodatages UNIX

Un nombre décimal positif ou négatif. Un nombre positif spécifie le nombre de secondes écoulées depuis l'itération (1970-01-01 00:00:00 UTC), et un nombre négatif spécifie le nombre de secondes avant l'itération. Les décimales sont conservées jusqu'à la sixième (précision à la microseconde).

Chaînes de date et heure

Chaîne de date et heure au format YYYY-MM-DD HH:MM:SS. Les spécificateurs UTC et Z sont acceptés.

Vous pouvez fournir un décalage horaire dans vos chaînes de date et heure, mais BigQuery ne conserve pas le décalage après la conversion de la valeur dans son format interne. Si vous devez conserver les données de fuseau horaire d'origine, stockez le décalage horaire dans une colonne distincte. Un décalage de fuseau horaire à un chiffre doit commencer par un zéro.

Les chaînes de date et heure doivent être indiquées lors de l'utilisation du format JSON.

Exemples

Les exemples suivants montrent des méthodes identiques pour décrire des dates spécifiques, dans un format d'horodatage UNIX et dans un format de chaîne de date et heure.

Événement Format d'horodatage UNIX Format de chaîne de date et heure
Tremblement de terre mineur (M4.2) près d'Oklahoma City

1408452095.220
1408452095.220000

2014-08-19 07:41:35.220 -05:00
2014-08-19 12:41:35.220 UTC
2014-08-19 12:41:35.220
2014-08-19 12:41:35.220000
2014-08-19T12:41:35.220Z
Neil Armstrong met le pied sur la Lune

-14182916

1969-07-20 20:18:04
1969-07-20 20:18:04 UTC
1969-07-20T20:18:04
Date limite pour corriger le bug Y10k

253402300800
2.53402300800e11

10000-01-01 00:00
DATE L'ancien SQL est compatible de façon limitée avec les données de type DATE. Pour en savoir plus, consultez la section Types de données de temps civil en ancien SQL.
TIME L'ancien SQL est compatible de façon limitée avec les données de type TIME. Pour en savoir plus, consultez la section Types de données de temps civil en ancien SQL.
DATETIME L'ancien SQL est compatible de façon limitée avec les données de type DATETIME. Pour en savoir plus, consultez la section Types de données de temps civil en ancien SQL.

Valeurs NUMERIC en ancien SQL

Vous pouvez lire les valeurs de type NUMERIC et les traiter avec des opérateurs non modificateurs tels que SELECT list (with aliases), GROUP BY keys, les champs d'intercommunication dans les fonctions analytiques, etc. Cependant, tout autre calcul sur des valeurs NUMERIC, y compris les comparaisons, produit des résultats non définis.

Les fonctions de conversion suivantes sont compatibles avec l'ancien SQL :

  • CAST(<numeric> AS STRING)
  • CAST(<string> AS NUMERIC)

Types de données de temps civil en ancien SQL

Vous pouvez afficher les types de données de temps civil (DATE, TIME et DATETIME) et les traiter avec des opérateurs non modificateurs tels que SELECT list (with aliases), GROUP BY keys, les champs d'intercommunication dans les fonctions analytiques, etc. En revanche, certains calculs sur les valeurs de temps civil, comme les comparaisons, produisent des résultats non définis.

Les fonctions de conversion suivantes sont compatibles avec l'ancien SQL :

  • CAST(<date> AS STRING)
  • CAST(<time> AS STRING)
  • CAST(<datetime> AS STRING)
  • CAST(<string> AS DATE)
  • CAST(<string> AS TIME)
  • CAST(<string> AS DATETIME)

En pratique, l'ancien SQL interprète les valeurs de temps civil comme des nombres entiers, et les opérations sur des nombres entiers qui, selon vous, sont des valeurs de temps civil produisent des résultats inattendus.

Pour calculer des valeurs à l'aide de types de données de temps civil, utilisez le langage SQL standard, qui est compatible avec toutes les opérations SQL sur les types de données DATE, DATETIME et TIME.

Étapes suivantes

  • Pour définir le type de données d'un champ à l'aide de l'API, consultez la section schema.fields.type.
  • Pour connaître les types de données compatibles avec le SQL standard, consultez la page relative aux types de données.