Comment UNION ALL BY NAME révolutionne-t-il vos requêtes BigQuery SQL ?

UNION ALL BY NAME supprime le casse-tête des colonnes mal alignées dans BigQuery en unionnant les résultats via les noms de colonnes, pas leur ordre. C’est un gain de temps et évite les erreurs de type avec un traitement plus intelligent, confirmé par la documentation officielle Google Cloud.

3 principaux points à retenir.

UNION ALL BY NAME aligne les colonnes par nom, plus besoin de respecter l’ordre exact.
Compatible avec colonnes mêmes types même si l’ordre diffère, le résultat est correct.
Optimise la maintenance des requêtes longues et complexes, évitant erreurs et confusion.

Qu’est-ce que UNION ALL BY NAME en SQL BigQuery et pourquoi c’est utile ?

Pour vulgariser les choses, UNION ALL BY NAME est votre nouvel allié dans l’univers de BigQuery SQL. Contrairement à une union SQL classique qui mélange des résultats en se fiant à l’ordre des colonnes, l’option BY NAME va plus loin en associant les colonnes par leur nom. Cela peut sembler anodin, mais laissez-moi vous dire que cette simple amélioration va révolutionner votre manière d’écrire des requêtes.

Dans une union SQL classique, les choses peuvent rapidement tourner au vinaigre. Prenons un exemple :

SELECT id, name, age FROM users1
UNION ALL
SELECT name, age, id FROM users2;

Dans ce cas, ça ne fonctionne pas — les colonnes ne correspondent pas, car l’ordre est différent. Si vous ne faites pas attention, vous risquez d’avoir des résultats incohérents, voire des erreurs. Tout codeur vous dira que les erreurs de position des colonnes sont courantes, surtout dans des bases de données massives où tout change constamment.

Maintenant, regardons le même scénario mais avec UNION ALL BY NAME :

SELECT id, name, age FROM users1
UNION ALL BY NAME
SELECT name, age, id FROM users2;

Ici, même si les colonnes ne sont pas dans le même ordre, BigQuery va magiquement associer les données par les noms des colonnes. Les résultats ? Parfaits. Pas de casse-tête, pas d’erreurs. Quel soulagement pour le développement, le débogage et la maintenance de votre code !

Cette fonctionnalité est d’autant plus utile pour les équipes qui collaborent sur des projets où le schéma peut changer ou évoluer. Cela réduit les risques d’erreurs humaines et permet de passer moins de temps à traquer les problèmes de syntaxe. En gros, vous pouvez vous concentrer sur l’analytique plutôt que sur les détails du code qui peuvent vous faire perdre un temps précieux. Qui pourrait dire non à ça ? Cette option améliore non seulement la productivité mais aussi la qualité du travail. Pour en savoir plus sur les variantes de SQL dans BigQuery, consultez cette documentation.

Comment utiliser UNION ALL BY NAME concrètement dans vos requêtes BigQuery ?

Pour utiliser UNION ALL BY NAME dans vos requêtes BigQuery, la syntaxe est d’une simplicité déconcertante : il suffit de préciser les colonnes par leur nom, peu importe leur ordre dans les tables. Voici un exemple concret :

-- Table A
CREATE TABLE A (id INT64, name STRING, value FLOAT64);
INSERT INTO A VALUES (1, 'Alice', 10.0), (2, 'Bob', 20.0);

-- Table B
CREATE TABLE B (name STRING, value FLOAT64, id INT64);
INSERT INTO B VALUES ('Charlie', 30.0, 3), ('David', 40.0, 4);

-- UNION ALL BY NAME
SELECT * FROM A
UNION ALL BY NAME
SELECT * FROM B;

Dans cet exemple, on voit que les tables A et B ont des colonnes dans un ordre différent. Pourtant, grâce à UNION ALL BY NAME, nous évitons les erreurs classiques dues à l’alignement des colonnes. Cela nous permet de récupérer toutes les lignes avec leurs valeurs respectives, quel que soit l’ordre des colonnes.

-- Résultat concret
-- id | name    | value
-- 1  | Alice   | 10.0
-- 2  | Bob     | 20.0
-- 3  | Charlie  | 30.0
-- 4  | David   | 40.0

Imaginons maintenant une légère variation dans l’ordre des colonnes, mais avec les mêmes noms et types :

-- Table C
CREATE TABLE C (value FLOAT64, id INT64, name STRING);
INSERT INTO C VALUES (50.0, 5, 'Eve');

-- UNION ALL BY NAME
SELECT * FROM A
UNION ALL BY NAME
SELECT * FROM C;

Le résultat sera identique, sans erreur, car le nom des colonnes reste constant. C’est là tout l’intérêt de cette fonctionnalité : elle facilite la manipulation de données hétérogènes issues de diverses sources sans avoir à s’inquiéter de l’ordre des colonnes.

Pour tirer le meilleur parti de UNION ALL BY NAME, voici quelques conseils pratiques :

Testez avec des jeux de données variés pour identifier les erreurs que vous pourriez rencontrer.
Toujours valider les types de données dans les tables source pour éviter d’autres problématiques.
Utilisez des ressources comme StackOverflow pour voir comment d’autres utilisateurs résolvent des défis similaires.

En manipulant des données hétérogènes, UNION ALL BY NAME se révèle être un atout incontournable pour optimiser vos requêtes dans BigQuery.

Quels impacts UNION ALL BY NAME a-t-il sur la performance et les bonnes pratiques SQL ?

UNION ALL BY NAME, c’est quoi le buzz ? Est-ce que ça change la donne en termes de performance des requêtes BigQuery ? La réponse est : oui, mais avec des nuances. Selon des tests réalisés par Google, cette fonctionnalité permet d’accélérer le traitement des requêtes en évitant les erreurs de types et en facilitant l’assemblage de jeux de données structurés de façon différente. C’est un gain potentiel, mais difficile à quantifier précisément, car cela dépend grandement des cas d’utilisation. Pour en savoir plus, tu peux consulter les documents officiels de [BigQuery](https://cloud.google.com/bigquery/docs/reference/legacy-sql%3Fhl%3Dfr?utm_source=metrylo.com&utm_campaign=article-webanalyste.com&utm_medium=referral).

Côté bonnes pratiques, voilà quelques règles à garder en tête pour ne pas tomber dans le panneau :

Noms identiques : Avec UNION ALL BY NAME, il est crucial que les noms de colonnes soient parfaitement identiques, sinon tu risques de te retrouver avec une grosse salade orthographique dans tes résultats.
Types compatibles : Les types de données doivent être strictement compatibles. Par exemple, ne mélange pas des STRING avec des INT dans la même colonne sous peine de t’attirer des ennuis.

Accroche-toi, car il existe aussi des limites à cette fonctionnalité. UNION ALL BY NAME ne fonctionnera pas si tes tables ont des différences majeures dans leur structure. Si tu as un champ à 10 attributs sur une table et 15 sur une autre, ça ne va pas le faire. Dans ce cas-là, il vaut mieux se tourner vers un UNION ALL classique, qui récupère les données sans se soucier de la structure.

Pour t’y retrouver, voici un tableau récapitulatif qui t’aidera à faire un choix éclairé entre UNION ALL BY NAME et UNION ALL classique :

Critères	UNION ALL BY NAME	UNION ALL Classique
Performance	Potentiellement améliorée	Standard
Compatibilité de nom	Doivent être identiques	Non requis
Types de données	Doivent être compatibles	Peuvent être différents
Limites de structure	Différences majeures non supportées	Aucune contrainte stricte

Les débuts de UNION ALL BY NAME sont prometteurs, mais une maîtrise des bonnes pratiques s’avère indispensable pour éviter des pièges sournois dans tes analyses de données.

Est-ce que UNION ALL BY NAME est le nouvel indispensable pour vos requêtes BigQuery ?

UNION ALL BY NAME n’est pas un gadget : c’est une avancée pragmatique qui élimine un problème récurrent dans les requêtes SQL sous BigQuery. En s’appuyant sur les noms de colonnes plutôt que leur ordre, elle évite erreurs, facilite la lecture et réduit le temps passé à organiser ses données. Cette fonctionnalité s’inscrit parfaitement dans une démarche d’optimisation des workflows data, avec une maintenabilité accrue. Pour qui travaille régulièrement avec plusieurs jeux de données similaires mais non parfaitement harmonisés, c’est une vraie révolution qui vaut la peine d’être adoptée sans tarder.

FAQ

Quelles différences majeures entre UNION ALL et UNION ALL BY NAME dans BigQuery ?

UNION ALL combine les lignes en exigeant que les colonnes soient dans le même ordre et de types compatibles. UNION ALL BY NAME ignore l’ordre, s’appuie sur les noms des colonnes pour aligner les données, ce qui évite des erreurs courantes.

Est-ce que UNION ALL BY NAME supporte les colonnes avec des types différents ?

Non, les colonnes doivent avoir des types compatibles. Le nom seul ne suffit pas si les types sont incompatibles, cela génèrera une erreur.

Comment utiliser UNION ALL BY NAME dans une requête standard ?

On insère la clause BY NAME juste après UNION ALL, par exemple : SELECT … FROM … UNION ALL BY NAME SELECT … FROM … Cela dirige BigQuery à faire correspondre les colonnes par noms.

Cela a-t-il un impact sur la performance des requêtes ?

Selon les tests et la documentation Google Cloud, l’impact est négligeable. Le gain en productivité et en fiabilité dépasse largement ce petit surcoût, quand il existe.

Peut-on utiliser UNION ALL BY NAME avec d’autres systèmes SQL comme Snowflake ?

Oui, certains systèmes comme Snowflake supportent aussi UNION ALL BY NAME, renforçant l’interopérabilité. Toutefois, la syntaxe ou comportement peut varier, il faut toujours vérifier la documentation respective.

Franck Scandolera

⭐ Expert et formateur en Tracking avancé, Analytics Engineering et Automatisation IA (n8n, Make) ⭐

Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

Data & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.