Discussion :

[Alex]

Dites bonjour à GoogleSQL : Google a discrètement abandonné le nom ZetaSQL et rebaptisé son projet open source d'analyse et d'analyse syntaxique SQL « GoogleSQL »

Google a récemment mis à jour ses documents destinés au public afin d'utiliser le nom GoogleSQL, soulignant que le dialecte est commun à tous les produits. Le changement de nom du package open source vient compléter cette harmonisation. L'objectif principal est de réduire la confusion et de permettre aux ingénieurs d'identifier plus facilement la technologie, qu'ils soient clients de Google Cloud, membres du personnel interne ou contributeurs open source.

Google a officiellement renommé son projet open source ZetaSQL « GoogleSQL ». Cette mise à jour unifie la marque pour le dialecte SQL, l'analyse et les bibliothèques d'analyse syntaxique utilisées dans les services internes de Google, les plateformes cloud et la communauté externe de développeurs. GoogleSQL est le dialecte SQL standard pour les principaux services tels que BigQuery et Spanner.

Bien que les ingénieurs de Google aient appelé en interne le composant linguistique « GoogleSQL », l'entreprise n'utilisait pas à l'origine ce nom pour les descriptions externes des produits. Par conséquent, alors que le référentiel open source donnait accès à la même base SQL, il fonctionnait sous la bannière ZetaSQL, ce qui le séparait de la terminologie utilisée dans la documentation commerciale.

Google a récemment mis à jour ses documents destinés au public afin d'utiliser le nom GoogleSQL, soulignant que le dialecte est commun à tous les produits. Le changement de nom du package open source vient compléter cette harmonisation. L'objectif principal est de réduire la confusion et de permettre aux ingénieurs d'identifier plus facilement la technologie, qu'ils soient clients de Google Cloud, membres du personnel interne ou contributeurs open source.

Pour les développeurs, cette mise à jour ne nécessite aucune migration technique immédiate. Google précise qu'il s'agit principalement d'un changement de marque par rapport à ZetaSQL ; la technologie sous-jacente, les fonctionnalités et l'équipe d'ingénieurs restent les mêmes. Le référentiel open source continuera à fonctionner sous le nouveau nom. Cette unification clarifie la relation entre les outils open source et les moteurs d'entreprise. Elle confirme que l'analyseur syntaxique disponible sur GitHub prend en charge le dialecte SQL exact utilisé dans BigQuery et Spanner. En consolidant la terminologie, Google vise à renforcer l'écosystème et à améliorer l'accessibilité pour sa base d'utilisateurs.

Présentation de SQL dans BigQuery

GoogleSQL est un langage de requête structuré (SQL) conforme à la norme ANSI, qui inclut les types d'instructions compatibles suivants :

- Les instructions de requête, également appelées instructions de langage de requête de données (Data Query Language), constituent la méthode principale d'analyse des données dans BigQuery. Elles analysent une ou plusieurs tables ou expressions, et renvoient des lignes de calculs de résultats. Les instructions de requête peuvent inclure la syntaxe pipe.

- Les instructions de langage procédural sont des extensions procédurales de GoogleSQL qui vous permettent d'exécuter plusieurs instructions SQL dans une seule requête. Les instructions procédurales peuvent utiliser des variables et des instructions de flux de contrôle, et peuvent avoir des effets secondaires.

- Les instructions LDD (langage de définition de données) vous permettent de créer et de modifier des objets tels que les suivants : Ensembles de données, Tables, y compris leur schéma et les types de colonnes, Clones et instantanés de table, Vues, Fonctions, Index, Engagements, réservations et attributions de capacité, Règles d'accès au niveau des lignes

- Les instructions LMD (langage de manipulation de données) vous permettent de mettre à jour, d'insérer et de supprimer des données dans vos tables BigQuery.

- Les instructions LDD (langage de contrôle de données) vous permettent de contrôler les ressources système BigQuery telles que l'accès et la capacité.

- Les instructions TCL (Transaction Control Language) vous permettent de gérer les transactions pour les modifications de données.

- Les instructions de chargement et les instructions d'exportation pour gérer les données entrantes et sortantes de BigQuery.

Voici l'annonce de Google :

ZetaSQL est rebaptisé GoogleSQL

Nous sommes ravis d'annoncer un changement mineur, mais important : le projet open source connu sous le nom de ZetaSQL a été officiellement renommé GoogleSQL (https://github.com/google/googlesql). Cette décision permet d'unifier le nom de notre puissant dialecte SQL et de nos bibliothèques d'analyse et d'interprétation sous une seule et même bannière, que vous l'utilisiez dans le cloud et les services internes de Google ou dans le cadre de la communauté open source.

Depuis des années, GoogleSQL est le dialecte SQL standard de nombreux services Google tels que BigQuery et Spanner. À l'origine, bien que nous appelions le composant linguistique GoogleSQL en interne, nous n'utilisions pas ce nom pour décrire le dialecte dans nos produits destinés au grand public. Depuis, nous avons commencé à utiliser le nom GoogleSQL dans nos produits et notre documentation destinés au grand public, afin de souligner qu'il s'agit du même dialecte partagé par tous les produits.

Aujourd'hui, nous renommons également le package open source afin de souligner qu'il prend en charge le même dialecte SQL que celui utilisé dans BigQuery, Spanner et d'autres produits. L'objectif de l'open source a toujours été de permettre aux développeurs extérieurs à Google de tirer parti de la même base SQL robuste et conforme. Avec ce changement de nom, nous souhaitons réduire la confusion et permettre à chacun de trouver et de discuter plus facilement de cette technologie exceptionnelle. Que vous soyez ingénieur interne, client Google Cloud ou développeur open source, vous utilisez GoogleSQL.

Il s'agit principalement d'un changement de marque. La technologie, les fonctionnalités et l'équipe qui la soutient restent les mêmes. Le référentiel open source continuera à prospérer, arborant désormais fièrement le nom GoogleSQL. Nous pensons que cette unification renforcera l'écosystème GoogleSQL, le rendant plus accessible et plus compréhensible pour notre communauté croissante d'utilisateurs et de contributeurs.

Nous sommes enthousiasmés par ce nouveau chapitre de GoogleSQL dans le monde open source et nous nous réjouissons de poursuivre notre collaboration et notre innovation avec la communauté.

Source : Annonce de Google

Et vous ?

Pensez-vous que cette annonce est crédible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

Google affirme que son agent LLM « Big Sleep » a découvert une vulnérabilité zero-day exploitable dans SQLite. L'entreprise estime que l'IA pourrait être l'avenir de la détection de bogue dans les logiciels

SQL à 50 ans : comment ce vétéran de la technologie continue-t-il à prospérer dans un paysage en constante mutation ? Une leçon sur la façon de rester pertinent en matière de données

Le Big Data serait mort, d'après Jordan Tigani, ingénieur fondateur de Google BigQuery, alors que pour IDC, le marché du Big Data enregistrera une forte croissance dans les années à venir

[SQLpro]

pas mal pour des gens qui "chiaient" sur SQL avec le NoSQL, mouvement visant à renverser l'hégémonie des bases de données relationnelles, basé sur l'arnaque du théorème CAP biaisé... !
Il est vrai que quelques années après l'annonce que le NoSQL allait remplacer les SGBDR, rien ne s'est passé comme prévu et Google et ses petits copains ont alors affirer que NoSQL signifiait "Not Only SQL".... Bref, comment prendre les informations pour des c... !

A +

[Michel.Priori]

NoSQL signifiait "Not Only SQL

Ah, mais alors Cobol c'est du NoSQL alors : on y manipule des données sans pour autant passer par du SQL.
Merci, ça m'avait échappé !

[Pierre Louis Chevalier]

Oui la gestion fichiers de COBOL c'est l'ancêtre de NOSQL, et cela a un sens parce que cela revient à micro manager les accès fichiers, donc du travail manuel à l'ancienne, au lieu de demander au SGBDR de se démerder comme il peut, avec plus ou moins de bonheur.
Ceci dit tu peux quand même faire du SQL avec COBOL, par exemple avec une connexion DB2, qui est bien un SGBDR SQL.

[escartefigue]

On est très en marge du sujet, mais je me permets quand même de rebondir sur les dernières réponses qui peuvent porter à confusion.

COBOL est un langage qui, comme bien d'autres, autorise l'inclusion d'ordres SQL.
Quand c'est le cas, la précompilation d'un programme COBOL commence par séparer d'un coté le COBOL proprement dit qui sera ensuite compilé et link-édité pour constituer le load module exécutable et les ordres SQL de l'autre pour constituer le DBRM qui lui, sera "bindé" pour calculer un plan d'exécution et constituer un package.
À l'inverse, les fichiers séquentiels et les fichiers indexés hors bases de données sont traités directement par le langage COBOL.

Autrement dit, le COBOL à proprement parler n'accède jamais aux bases de données relationnelles, c'est le package associé au load module qui le fait.

Et pour garantir la cohérence entre le package et le load module, un identifiant unique, appelé "consistency token", est affecté lors de la précompilation. Lors de l'exécution, le "consistency token" du load et du package sont comparés, et s'ils divergent, alors il y a plantage avec message d'erreur.

Par ailleurs, en tout cas sur Z/OS qui va souvent de pair avec COBOL, quand un fichier appartient à une base de données, qu'elle soit relationnelle ou pas, on peut en interdire l'accès directement par l'OS de sorte à garantir l'intégrité.

[SQLpro]

...
Ceci dit tu peux quand même faire du SQL avec COBOL, par exemple avec une connexion DB2, qui est bien un SGBDR SQL.

Ho les joies de SQL "embedded" avec les curseurs, l'ancêtre des composants d'accès de type ODBC et autres !

A +

[Escapetiger]

pas mal pour des gens qui "chiaient" sur SQL avec le NoSQL, mouvement visant à renverser l'hégémonie des bases de données relationnelles, basé sur l'arnaque du théorème CAP biaisé... ! (.../...)

Pour celles et ceux pour lesquel.le.s les bases de données ne sont pas forcément le quotidien:

Théorème CAP - Wikipedia

« Le théorème CAP ou CDP, aussi connu sous le nom de théorème de Brewer, dit qu'il est impossible sur un système informatique de calcul distribué de garantir en même temps (c'est-à-dire de manière synchrone) les trois contraintes suivantes :

• Cohérence (Consistency en anglais) : tous les nœuds du système voient exactement les mêmes données au même moment ;
• Disponibilité (Availability en anglais) : garantie que toutes les requêtes reçoivent une réponse ;
• Tolérance au partitionnement (Partition Tolerance en anglais) : aucune panne moins importante qu'une coupure totale du réseau ne doit empêcher le système de répondre correctement (ou encore : en cas de morcellement en sous-réseaux, chacun doit pouvoir fonctionner de manière autonome).

D'après ce théorème, un système de calcul/stockage distribué ne peut garantir à un instant t que deux de ces contraintes mais pas les trois... »