Discussion :

[Bill Fassinou]

Nous pouvons faire mieux que SQL qui présente quelques lacunes,
selon Elvis Pranskevichus

La taille des données traitées par les entreprises augmente chaque jour et le Big Data est en plein essor. Les entreprises sont aujourd’hui à la recherche de solutions plus rapides, plus sécurisées et plus optimales pour manipuler toutes ses données. À cet effet, le SQL (Structured Query Language) est depuis plusieurs décennies le langage le plus utilisé pour accéder aux bases de données, mais pour certains, cela ne signifie pas nécessairement que le SQL représente le meilleur de ce que nous pouvons faire. Selon une analyse que propose Elvis Pranskevichus sur le langage de traitement de données, le langage SQL destiné aux requêtes ad hoc possédait dès le départ un bagage de problèmes graves.

Le langage SQL peut être considéré comme le langage d'accès normalisé aux bases de données. Il est aujourd'hui supporté par la plupart des produits commerciaux que ce soit par les systèmes de gestion de bases de données micro tel que Access ou par les produits plus professionnels tels que Oracle, mais beaucoup commencent à juger que le langage SQL est de plus en plus inadapté pour la manipulation des nouveaux types de données que l’homme est en train de générer depuis quelques années maintenant. L’exemple premier qu’ils donnent est celui des données générées par les médias sociaux (les données audio, vidéo, et.) qui sont des données dites non structurées. L’alternative qu’utilisent certaines entreprises à ce niveau est d’analyser ces données à l’aide d’une base de données NoSQL.

De son côté et en se basant sur des tests réalisés avec PostgreSQL, Elvis Pranskevichus a essayé de regrouper les lacunes du langage SQL en quatre catégories. Il cite notamment le manque d’orthogonalité appropriée de SQL (SQL est difficile à composer), son manque de compacité (SQL est un langage volumineux), son manque de cohérence (SQL est incohérent dans la syntaxe et dans la sémantique) et sa mauvaise cohésion avec le système c’est-à-dire que le langage SQL ne s'intègre pas assez bien avec les langages et les protocoles d'application. Certaines de ces plaintes présentées ci-dessus, dit-il, concernent SQL dans son ensemble, tandis que d'autres sont spécifiques à une implémentation donnée.

Il a expliqué que l'orthogonalité dans un langage de programmation signifie qu'un ensemble relativement petit de constructions primitives peut être combiné de manière relativement réduite. Un langage avec une bonne orthogonalité est plus petit, plus cohérent et plus facile à apprendre, car il existe peu d'exceptions à l'ensemble des règles. Inversement, une mauvaise orthogonalité conduit à un langage large avec de nombreuses exceptions et mises en garde. Un bon exemple d'orthogonalité dans un langage de programmation est la possibilité de substituer une partie arbitraire d'une expression par une variable, ou un appel de fonction, sans aucun effet sur le résultat final. En SQL, a-t-il indiqué, une telle substitution générique n’est pas possible, car il existe deux types d’expressions incompatibles.

D’après lui et les propos de Pablo Atzeni, professeur à l’université de Rome et chercheur en base de données, le manque de compacité du langage SQL vient du fait que sa standardisation ou sa normalisation appartient en grande partie aux fournisseurs de bases de données, et non aux chercheurs universitaires sans intérêts commerciaux ou aux utilisateurs ayant des intérêts d'utilisateurs. Un exemple qu’il a donné par rapport à cela est que l'implémentation de PostgreSQL contient 469 mots-clés. La partie 2 seule (sur 14) de la norme SQL:2016 comprend 1732 pages. Il poursuit en disant que l’une des raisons principales à la prolifération de mots clés dans le langage est qu’on veuille faire en sorte qu’il soit adapté aux “non-professionnels”.

« La raison principale est que SQL, conformément à ses objectifs initiaux, s'efforce d'être un langage de type anglais, adaptée aux « non-professionnels ». Cependant, avec la croissance du langage, cette verbosité a contribué négativement à la capacité d'écrire et de comprendre les requêtes SQL. Nous avons appris cette leçon avec COBOL et le monde a depuis longtemps adopté des langages de programmation plus récents et plus succincts », a-t-il déclaré. Il entame par la suite sa critique sur le manque de cohérence du langage dans sa syntaxe et sa sémantique en disant que cela aggrave encore plus les choses, c'est que différentes bases de données ont leur propre version de SQL, souvent incompatible avec d'autres variantes de SQL.

À cela, un internaute a déclaré ce qui suit : « Je ne suis pas en désaccord avec le fait que SQL peut encore être amélioré. C'est l'une des principales raisons pour lesquelles j'utilise PostgreSQL en premier lieu, car de nombreuses améliorations sont disponibles en plus de SQL. Cela dit, SQL est sacrément efficace. En tant que langage, c'est la véritable colonne vertébrale d'Internet aujourd'hui. Il est lisible, explicite, assez concis et traduit naturellement la manière dont les données doivent être décomposées pour un stockage efficace et permettre une récupération plus efficace. Il existe des différences entre les implémentations de différents fournisseurs, mais cela sert à trouver des solutions à des défauts d’implémentations chez les autres fournisseurs et les améliorer pour créer un meilleur produit. Je souhaite bonne chance aux gens dans leur travail pour améliorer les choses, mais le langage sur lequel je me suis appuyé régulièrement ces dernières années est le SQL et j'ai travaillé avec beaucoup de langages. SQL est celui qui exécute le plus correctement et me laisse le moins souvent tomber ».

Elvis Pranskevichus

Selon Pranskevichus, ces différentes faiblesses que présente le SQL nuisent à l’ergonomie des différentes applications. L'orthogonalité, la compacité et la cohérence, a-t-il fait remarquer, sont les caractéristiques essentielles d'un langage de programmation facile à apprendre et à utiliser efficacement à tous les niveaux d'expertise, de taille d'équipe et de complexité du projet. Pour finir avec les critiques, il évoque le fait que le mouvement NoSQL est né en partie de la frustration suscitée par la stagnation et l’insuffisance perçues des bases de données SQL.

Pour remédier à ces différents soucis que pose le SQL que nous connaissons, ce que propose Pranskevichus est de parvenir à créer une meilleure version de SQL pour les utilisations futures et pouvoir manipuler les données de demain à bon escient. Sa solution à lui, c’est EdgeQL, un langage qui, selon lui, met l'accent sur la convivialité, la performance sans compromettre l'exactitude et résout l’ensemble des problèmes précités. D’après la documentation proposée à l’outil, EdgeDB est une base de données relationnelle-objet qui stocke et décrit les données sous forme d'objets fortement typés et leurs relations. La documentation précise qu’EdgeDB est construit sur PostgreSQL, héritant de toutes ses forces principales : conformité ACID, performances et fiabilité.

La base de données EdgeDB disposerait des caractéristiques suivantes : schéma strict et fortement typé, possède un langage de requête propre et puissant, permet de travailler facilement avec des données hiérarchiques complexes et propose un support intégré pour les migrations de schéma. La documentation de l’outil renseigne également qu’EdgeDB n'est pas une base de données graphique, les données sont stockées et interrogées à l'aide de techniques de base de données relationnelle. Contrairement à la plupart des bases de données graphiques, EdgeDB maintient un schéma strict. Il est aussi écrit qu’EdgeDB n’est pas une base de documents, mais insérer et interroger des données hiérarchiques de type document est une tâche triviale. L’autre chose qu’on peut noter également est qu’EdgeDB n’est pas une base de données objet traditionnelle. Malgré la classification, précise la documentation, il ne s’agit pas d’une implémentation de la persistance POO (programmation orientée objet).

« SQL a commencé avec l'objectif de permettre aux non-programmeurs de travailler efficacement avec les données relationnelles. Malgré ses faiblesses, il a sans doute eu un succès retentissant, la plupart des bases de données l'implémentant ou le reproduisant. Cependant, comme toute solution, SQL est confronté à une insuffisance croissante dans la prise en charge des nouvelles exigences, des nouveaux modes d’utilisation et de la productivité des utilisateurs. Il est temps que nous agissions », a conclu Elvis Pranskevichus.

Source : Billet de blog

Et vous ?

Qu'en pensez-vous ?
Êtes-vous de l'avis de Elvis Pranskevichus ?
Pensez-vous qu'EdgeQL puisse remplacer le SQL ? Pourquoi ?

Voir aussi

AlaSQL.js, une base de données SQL JavaScript pour le navigateur et Node.js, est désormais disponible et serait rapide et très flexible

La version 5.3.2 de DBeaver, l'outil de base de données multiplateforme, est disponible, tour d'horizon des principales nouveautés

Google lance Cloud Firestore, une base de données de documents NoSQL sans serveur, serait-elle meilleure que Firebase ?

[NotAèfka]

Nous pouvons faire mieux que html surtout.

[pachot]

Je suis très étonné de voir cet article (je parle de l'original) en 2019. La tendance 'NoSQL' initiée par ceux qui n'ont pas compris/appris SQL (comme l'auteur le l'article) n'a pas duré longtemps. Aujourd'hui, toutes les solutions alternatives reviennent au SQL, que ce soit pour le BigData ou l'OLTP (exemple: Spark, Kafka, Spanner,...). On voit bien l'incomprehension (sur le language et le relationnel) de l'auteur de l'article dans ses exemples 'orthogonalité'. Vouloir remplacer une variable 'scalar expression' par 'table expression' c'est comme confondre une variable avec un tableau d'enregistrements...
Et proposer une base de donnée 'relationnelle-objet' en 2019... c'est idée révolutionnaire des années 80! Aujourd'hui, les bases de données objet sont mortes, et les extensions relationnel-object' jamais utilisées.
Mais le résumé est très bien. C'est sur l'article de Elvis Pranskevichus et l'idée de EdgeQL que je suis très sceptique...

[MaximeCh]

...

Joli analyse.
Je trouve que - ou plutôt je cherche à comprendre pourquoi - SQL a une lacune immense : il est pas du tout utilisé en OLAP, en BI, bref en analyse sérieuse des données.
Pour un langage qui s'appelle search query, et dont le sous-ensemble le plus solide, mature, standard, est le Data Query Language, c'est quand même un comble!
Ca fait un moment que je me demande si ce n'est pas lié au fait que les big brains, Codd, Date... ont écarté les logiques d'ordre supérieur...

[pachot]

Pour un langage qui s'appelle search query

Non. 'Structured Query Language', pas 'Search'. C'est un language structuré (=qui suit la sémantique des opérations d'algèbre relationnelle) qui est utilisé pour toute définition et manipulation de donnée. Avec deux déclinaisons: pour programmer (curseurs, bind variables,...) et pour utilisation ad-hoc par l'utilisateur final - exactement la BI.

SQL a une lacune immense : il est pas du tout utilisé en OLAP, en BI, bref en analyse sérieuse des données.

Alors là je ne comprend pas d'où vient cette idée. Justement, l'indépendance entre le modèle physique et logique, et le fait que ce soit un language déclaratif (l4G) sont les clés la clé de son utilisation en BI. Avec un language procédural (l3G) on doit connaitre à l'avance comment vont être interrogées les données, pour coder l'accés. Avec un L4G, comme SQL, on décrit seulement le résultat et l'optimiseur construit le plan d'exécution (procédural) pour aller chercher les données.

SQL:2003 définit les functions analytiques (window function) et la plupart des SGBD les implémentent aujourd'hui. C'est la clé de la BI. Toute la BI aujourd'hui utilise SQL. Soit par des SGBD relationnels qui l'ont depuis toujours, soit par les nouveaux Big Data qui l'ont adopté. Faire du code procédural pour analyser des données non structurées n'est efficace que pour un use-case donné. Les requêtes ad-hoc c'est toujours le domaine de SQL.

Je suis curieux de savoir d'où vient cette idée que SQL n'est "pas du tout utilisé en OLAP, en BI".

[MaximeCh]

Non. 'Structured Query Language', pas 'Search'.

Oulà oui, pas réveillé...

SQL:2003 définit les functions analytiques (window function) et la plupart des SGBD les implémentent aujourd'hui. C'est la clé de la BI. Toute la BI aujourd'hui utilise SQL. Soit par des SGBD relationnels qui l'ont depuis toujours, soit par les nouveaux Big Data qui l'ont adopté. Faire du code procédural pour analyser des données non structurées n'est efficace que pour un use-case donné. Les requêtes ad-hoc c'est toujours le domaine de SQL.

Je suis curieux de savoir d'où vient cette idée que SQL n'est "pas du tout utilisé en OLAP, en BI".

Les window functions font du bien au langage c'est sûr.
Dans toutes les boîtes où j'ai travaillé, on m'a asséné qu'on faisait pas de BI en SQL, parce que SQL ne gère pas les (hyper)cubes, (et que de toutes façons il fallait utiliser M$ PowerBI).
Bon c'est sûr dans ces entreprises, même à la DSI, il n'y avait pas de génies de l'informatique, mais il doit y avoir un fond de vérité...
Edit : deux liens, cubes OLAP et MDX.

Edit 2: Pour résumer ce que j'ai vu, le SQL est utilisé pour extraire des ERP, xMS, APS &co vers un datawarehouse, et ensuite les outils/langages dédiés prennent le relai.

[yahiko]

Sceptique par ce EdgeSQL. A vouloir améliorer le SQL, ce qui est toujours louable dans les intentions, on finit toujours par ajouter une nième variante à SQL ce qui est la plaie quand il s'agit de bosser sur des systèmes hétérogènes avec des SGBDR différents.

Le SQL a ses lacunes, mais quand je vois que beaucoup ont du mal avec la simple approche relationnelle, le EdgeSQL à vouloir faire quelque chose de compact et d'élégant (ce qu'il est peut-être, je n'ai lu qu'en diagonal les exemples), me semble complètement hors de portée intellectuellement parlant pour les développeurs sous-payés et sous-formés à qui on demande de pisser de la requête à l'arrache.

En résumé, bien tenté, mais aucune chance de percer.

[AoCannaille]

. A vouloir améliorer le SQL, ce qui est toujours louable dans les intentions, on finit toujours par ajouter une nième variante à SQL

ça me fait un peu penser à cet strip d'XKCD :

[esperanto]

Un bon exemple d'orthogonalité dans un langage de programmation est la possibilité de substituer une partie arbitraire d'une expression par une variable, ou un appel de fonction, sans aucun effet sur le résultat final. En SQL, a-t-il indiqué, une telle substitution générique n’est pas possible, car il existe deux types d’expressions incompatibles.

C'est vrai que les expressions de type WITH sont arrivées assez tardivement et que même maintenant qu'elles sont là, elles restent difficiles à écrire et verbeuses.
Un exemple de requête difficile à exprimer en SQL alors qu'elle est facile en langage humain: renvoyer tous les résultats de la requête R1, ou tous les résultats de la requête R2 si et seulement si la requête R1 n'a aucun résultat. Ce qui est très utile par exemple pour faire des compromis: genre, R1 = recherche de termes exacts et R2 = recherche de termes approchants (uniquement si la recherche exacte n'a rien donné)

« La raison principale est que SQL, conformément à ses objectifs initiaux, s'efforce d'être une langue de type anglais, adaptée aux « non-professionnels ». Cependant, avec la croissance du langage, cette verbosité a contribué négativement à la capacité d'écrire et de comprendre les requêtes SQL. Nous avons appris cette leçon avec COBOL

C'est vrai que par beaucoup d'aspects SQL me fait penser à COBOL: par exemple quand on regarde les types de données avec un nombre de chiffres plutôt qu'un nombre de bits. Heureusement qu'on n'a plus à se farcir les packed-decimal, manquerait plus que ça.

Pour remédier à ces différents soucis [...] Sa solution à lui, c’est EdgeQL

Intéressant, c'eut été encore mieux de mettre au moins un lien dans l'article pour qu'on puisse comparer. Surtout que dans l'original en anglais, il semble bien y avoir des exemples. Bon je vais chercher et étudier ça de plus près, difficile de se faire un avis sinon.

La tendance 'NoSQL' initiée par ceux qui n'ont pas compris/appris SQL (comme l'auteur le l'article) n'a pas duré longtemps.

C'est cela, oui...
C'est surtout que les communicants des grands vendeurs de bases SQL n'ont pas tardé à réagir et à faire croire aux décideurs des grandes entreprises qu'ils pouvaient faire la même chose. De toute façon les décideurs de grandes entreprises écoutent toujours en priorité ceux qui sont déjà leurs fournisseurs (contrairement aux startups, qui ont au moins le mérite de réellement s'intéresser à la technique)

Vous vous rappelez des bases de données objet, de l'organisation ODMG?
A l'époque, les experts SQL ont réussi à faire croire à tout le monde que ce modèle était plus lent que le leur. En réalité, quand on examinait les benchmarks, on se rendait compte que ceux-ci comparaient une base SQL spécialement optimisée pour le problème à résoudre avec un modèle objet écrit par un étudiant qui ne savait pas encore vraiment ce qu'était une classe. Les dés étaient donc pipés dès le départ.
Résultat:

1. Même l'extension objet de SQL, dite relationnelle-objet ou SQL 3, bien qu'il s'agisse du dernier standard officiel, est encore passablement ignorée de la plupart des DBA. Il m'est déjà arrivé de venir avec un modèle SQL 3 pour un projet et de le voir converti par le DBA qui n'y comprenait rien...
2. Comme entre temps les langages comme Java ont fini par supplanter Cobol, mais que les DBA ne veulent pas de SQL 3, on a fini par se retrouver avec des saloperies genre Hibernate (désolé mais même si je suis développeur et pas DBA, je comprends quand même suffisamment le modèle pour voir au premier coup d’œil que les requêtes générées par Hibernate sont non seulement pas optimisées mais probablement pas optimisables non plus...)

Aujourd'hui, toutes les solutions alternatives reviennent au SQL, que ce soit pour le BigData ou l'OLTP (exemple: Spark, Kafka, Spanner,...)

Évidemment, les promoteurs de SQL ont su comment réagir: en créant d'abord un type XML, puis JSON. Maintenant je suis sûr qu'on va voir fleurir les bases SQL avec une seule table ayant un seul champ de type JSON (je caricature à peine)

Sauf que si tu connaissais vraiment aussi bien NoSQL que tu prétends connaître SQL, tu saurais que le typage fort - qui n'est plus pertinent quand les données sont trop hétérogènes - n'était qu'une partie du problème auquel NoSQL essaie de répondre. Je n'ai par exemple jamais vu de base SQL répartie qui accepte de sacrifier la cohérence pour la rapidité, ce qui est parfois utile (parfois je préfère recevoir rapidement une donnée un peu ancienne que d'attendre que toutes les bases aient été rafraichies pour être sûr d'avoir la plus récente).

[pachot]

Un exemple de requête difficile à exprimer en SQL alors qu'elle est facile en langage humain: renvoyer tous les résultats de la requête R1, ou tous les résultats de la requête R2 si et seulement si la requête R1 n'a aucun résultat. Ce qui est très utile par exemple pour faire des compromis: genre, R1 = recherche de termes exacts et R2 = recherche de termes approchants (uniquement si la recherche exacte n'a rien donné)

presque une traduction mot à mot du language humain:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
with 
"recherche exacte" as (
  select * from DEMO where TEXT='SQL'
  ), 
"recherche approximative" as (
  select * from DEMO where TEXT like '%SQL'
  )
select * from "recherche exacte" R1
union all
select * from "recherche approximative" R2
where (select count(*) from "recherche exacte")=0
;

exemple: http://sqlfiddle.com/#!4/d5818/3
Regarde le plan d'exécution: le full scan n'est exécuté que si la recherche exacte, via index, n'a rien trouvé. On ne peut pas faire plus optimal.

Sur les SGBDOO et le NoSQL, je crois plus à un point de vue pragmatique performance/consistence/agilité plutôt qu'un complot des éditeurs. Et sur le "typage fort qui n'est plus pertinent..." on en reparle quand dans 10 ans quand il faudra scanner les données hétérogènes pour trouver ce qui ressemble à un nom pour raison GDPR ou à un numéro de carte bancaire pour raison de sécurité. Oh, et "les types de données avec un nombre de chiffres plutôt qu'un nombre de bits" ils sont indispensable pour compter sans erreur d'arrondi, parce que les humains et les banquiers ne comptent pas en bits, et aiment bien les comptes justes. Les startups peuvent partir sur du NoSQL pour compter les likes, mais ils n'ont pas mis leur ERP sur MongoDB

[esperanto]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
with 
"recherche exacte" as (
  select * from DEMO where TEXT='SQL'
  ), 
"recherche approximative" as (
  select * from DEMO where TEXT like '%SQL'
  )
select * from "recherche exacte" R1
union all
select * from "recherche approximative" R2
where (select count(*) from "recherche exacte")=0
;

J'ai dit difficile, pas impossible. Dans ton expression on a quand même 4 "select *", ça pourrait être fastidieux si on devait énumérer les mêmes champs à chaque fois... surtout que UNION ALL impose une structure identique, ce qui montre bien que ce serait bien de factoriser.

[pachot]

J'ai dit difficile, pas impossible. Dans ton expression on a quand même 4 "select *", ça pourrait être fastidieux si on devait énumérer les mêmes champs à chaque fois... surtout que UNION ALL impose une structure identique, ce qui montre bien que ce serait bien de factoriser.

Ah. Je ne vois pas dans quel language ce pourrait être plus simple. Tout en garantissant la cohérence des données, la performance, la lisibilité, l'indépendance de l'implémentation physique,... Le nombre de select peut être réduit, mais c'est beaucoup mieux de séparer chaque composant si on doit rajouter des filtres plus complexes, et des commentaires, et tester un partie individuellement... Et il n'y a aucune raison d'énumérer les colonnes à chaque fois. Une fois est suffisant.

[esperanto]

Ah. Je ne vois pas dans quel language ce pourrait être plus simple.

En fait pour cette requête en particulier il manque juste à SQL un opérateur "short circuit or", capable d'évaluer la seconde opération si et seulement si la première n'a pas suffi à décider. Peut-être pas dans le where, mais au moins en alternative au UNION ALL.
Évidemment tu vas trouver mille et une raisons pour lesquelles ça ne pourrait pas marcher, mais je crois que ce devrait être à l'optimiseur de requêtes de reconstituer la série de 4 select à partir d'une expression factorisée.

[pachot]

En fait pour cette requête en particulier il manque juste à SQL un opérateur "short circuit or", capable d'évaluer la seconde opération si et seulement si la première n'a pas suffi à décider. Peut-être pas dans le where, mais au moins en alternative au UNION ALL.
Évidemment tu vas trouver mille et une raisons pour lesquelles ça ne pourrait pas marcher, mais je crois que ce devrait être à l'optimiseur de requêtes de reconstituer la série de 4 select à partir d'une expression factorisée.

Oui, on peut l'écrire avec in OR si on préfère et l'optimiseur fera OR EXPANSION pour le transformer en UNION ALL. Et l'optimiseur fait ce "short circuit" - cf. l'opération FILTER dans le plan d'exécution Oracle.
Tout ça existe dans le language SQL. son utilité est justement de ne pas avoir à spécifier commect ce sera exécuté, mais seulement décrire le résultat que l'on cherche. Et l'optimiseur se charge d'écrire le plan d'exécution.

C'est finalement une très bonne illustration de la puissance de SQL et du relationnel par rapport aux langages procéduraux et aux modèles hierarchiques comme OO/XML/JSON.

[tanaka59]

Les normes SQL sont allégrement bafoué : entre du SQL SAS , SQL MySQl , SQL Access , SQL Oracle .

Un group_concat chez MySQL ? On va proposer un proc transpose chez SAS ! Une fonction VBA usine à gaz sur Access ...

Ne parlons pas des inner join / join et des diezes gauche ou droite avec les anciennes normes de chez Oracles. L'histoire du top ou du limit aussi est pas mal.

Chaque société a décidé de plus ou moins faire ses propres normes. Résultat chacun a pris le SQL avec ces normes à lui . Penser que tout changer ou harmoniser est possible ... est illusoire.

Lier 2 tableaux avec des join est plus facile que de faire boucler un tableau de 2 millions d'enregistrements sur un tableau de 1 millions d'enregistrement . Imaginez le nombre de combinaisons à tout comparer O.O

[SQLpro]

C'est vrai que les expressions de type WITH sont arrivées assez tardivement et que même maintenant qu'elles sont là, elles restent difficiles à écrire et verbeuses.
Un exemple de requête difficile à exprimer en SQL alors qu'elle est facile en langage humain: renvoyer tous les résultats de la requête R1, ou tous les résultats de la requête R2 si et seulement si la requête R1 n'a aucun résultat. Ce qui est très utile par exemple pour faire des compromis: genre, R1 = recherche de termes exacts et R2 = recherche de termes approchants (uniquement si la recherche exacte n'a rien donné)

Vous trouvez cela difficile ? Moi pas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
WITH
R1 AS (SELECT ...),
R2 AS (SELECT ...)
SELECT * FROM   R1
UNION ALL
SELECT * FROM   R2 
WHERE  NOT EXISTS(SELECT * FROM R1)

Encore une fois il s'agit d'apprendre le SQL !

A +

PS pour information c'est un exercice que je donne à mes stagiaires en cours avancé de SQL...

[SQLpro]

Les normes SQL sont allégrement bafoué : entre du SQL SAS , SQL MySQl , SQL Access , SQL Oracle .
…
Chaque société a décidé de plus ou moins faire ses propres normes.
...

Non, justement ce ne sont pas des normes, ni des standards, mais des dialectes.
Note que Oracle qui étais il y a encore quelques années, le plus indiscipliné, comble son retard :

• COALESCE à la place DE NVL
• CAST en remplacment des TO_...
• CASE pour DECODE
• L'arrivée des COLLATIONS, des noms longs et de l'opérateur APPLY….

A +

[MaximeCh]

Bump si quelqu'un a la réponse à mon léger HS... ça fait des mois/des années que je cherche à comprendre

[Waldar]

Je n'ai par exemple jamais vu de base SQL répartie qui accepte de sacrifier la cohérence pour la rapidité, ce qui est parfois utile (parfois je préfère recevoir rapidement une donnée un peu ancienne que d'attendre que toutes les bases aient été rafraîchies pour être sûr d'avoir la plus récente).

C'est bien le fond du problème. La cohérence c'est l'acidité des transactions, le rafraîchissement de bases c'est autre chose (copie, backup, peu importe).
La cohérence n'est jamais sacrifiable car c'est l'enfer de redresser une base incohérente (entrepôt de données à part).

Quant à la rapidité, je suis chez Teradata depuis deux ans environ et on est "challengé" par les architectures NoSQL qui sont "gratuites".
Chez le client où j'interviens régulièrement, à volume et cluster physique équivalent (250 To / 8 noeuds), Teradata répond de 10 à 2000 fois plus vite tout en gérant 15 fois plus de charge.
Tous les PoC volumineux (500 Go de données) commencés sur le cluster hadoop finissent toujours chez nous, car en terme de fonctionnalité, de langage, de rapidité, rien ne tient la route côté NoSQL.

C'est surtout ça la réalité du NoSQL, une fausse promesse portée par des développeurs (souvent issu du monde Java) qui savent à peine se servir d'une base de données.
Les performances du cluster hadoop sont justes correctes quand on est seul mais s'effondrent dès qu'il y a un peu de concurrence (et je parle de 10, pas de 5000).

Je ne dis pas que tout est à jeter, en terme de stockage décentralisé à bas coût c'est une bonne solution.
Faire du "schema on read" a aussi son utilité ici ou là.
Mais le travail caché derrière NoSQL est simplement gigantesque : la promesse de réduction de coût n'est jamais tenue.

[Waldar]

Dans toutes les boîtes où j'ai travaillé, on m'a asséné qu'on faisait pas de BI en SQL, parce que SQL ne gère pas les (hyper)cubes, (et que de toutes façons il fallait utiliser M$ PowerBI).

Je fais de la BI depuis une vingtaine d'années, je peux vous dire que cette histoire de cubes OLAP c'est la grande escroquerie de la BI.
Notoirement poussé par MS car SQL-Server car au début des années 2000 SQL-Server c'était vraiment pas folichon.

Je suis intervenu dans beaucoup de sociétés différentes, avec des bases sur SQL-Server, de l'Oracle, du PostgreSQL, du Greenplum, du Teradata, de 50 Go à 300 To.
Les seuls qui font des cubes sont les clients SQL-Server.

Ceux qui ont d'autres bases n'en ont pas besoin, un datamart étoile / flocon bien modélisé et bien implémenté fait très bien le job.