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 compatibles avec ce langage, consultez la section relative aux types de données compatibles avec le 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.
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.
BOOLEAN
  • 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 sensible à 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

Une chaîne de date et heure au format YYYY-MM-DD HH:MM:SS. Les indicateurs UTC et Z sont disponibles.

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 section relative aux types de données.
Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…