SQL & éléphant

Ce texte de 2005 est un mélange bizarre entre : * du cours universitaire, dont on pourrait expurger un cinquième de redites et d’« enrobage » destiné à indiquer d’où il vient et pourquoi il n’a pas parlé de ci ou ça avant, mais Dieu merci avec très peu de formalisme mathématique ; * de précieux rappels sur ce qui est théorie et ce qui est raccourci syntaxique ou de performance dans le SQL — à garder à l’esprit ; sur les opérations ensemblistes qui sont parfois la même sous deux formes différentes en SQL ; sur la normalisation, en fait basée sur les projections ; sur les contraintes, absolument fondamentales, et que le SQL n’implémente que pauvrement (sans parler des concepteurs de base de données) ; * des pinaillages pas fondamentalement idiots mais bien trop longs sur ce qui est « relationnel » dans la théorie ; sur la distinction entre type et domaine, ou ”relations” et ”relvars” (ce dernier est à la relation ce que la valeur est à la variable) ; le dévoiement du mot « vue » ; le fait que les relations ne devraient pas posséder de doublons (les relations sont des ”ensembles”) ; l’@@UPDATE@@ qui n’existe pas en théorie ensembliste ; ou encore la présence ou pas de l’entête proprement dit dans la relation ; le stockage physique pas fondamental pour avoir une relation… et pourtant tous ces détails figurent comme ”teasers” dans la quatrième de couverture ; * des évidences qu’en tant que vétéran du SQL on devrait connaître, mais qu’il est bon de rappeler, comme les tables de vérités incluant @@NULL@@, la chasse à la redondance, ou le « bon sens ”formalisé” » derrière la normalisation d’un schéma, que bien des gens effectuent à l’instinct ; * des rappels sur certains dangers de ne pas suivre la logique de la théorie relationnelle (les contraintes différées au @@COMMIT@@ sont dangereuses, la cohérence des données n’est pas garantie dans les requêtes pendant la transaction ; les contraintes devraient s’appliquer à chaque ordre) ; et la ré-affirmation que le schéma ”physique” doit suivre le plus possible le schéma ”logique” : il faut être conscient de cela quand on fait ces choix ; * des remarques bienvenues sur certains aspects un peu flous, comme le concept d’atomicité (”tout” est décomposable, et on peut mettre des tableaux entiers dans un champ) ou la cohérence ; * de pénibles plaintes sur des croisades personnelles où Date veut refaire la théorie de Codd, par exemple à propos du @@NULL@@ qui ne devrait pas exister parce que dans certains cas tordus il permet des aberrations — alors que pour Codd ”himself” il aurait même fallu [distinguer « Inconnu » et « Inapplicable »|https://en.wikipedia.org/wiki/Null_(SQL)#History|en] (mais c’était trop demander aux développeurs) ; ou sur de possibles remplaçants du SQL pour coller plus au modèle relationnel ou répondre à de nouveaux besoins ; * de l’autopromotion pour ses autres livres et articles ; * des marottes personnelles comme le ”Tutorial D”, concurrent épuré du SQL pour TPs universitaires, peut-être utile très ponctuellement, mais bien loin de nos préoccupations concrètes ; * des conseils un peu bizarres pour les pros des bases dans le monde réel, comme la promotion de l’utilisation de la 6è Forme Normale (si j’ai bien compris, les tables sont tellement éclatées qu’il n’y a plus besoin de @@NULL@@) ou le @@DISTINCT@@ systématique (!) pour des raisons simplement théoriques. J’ai allègrement sauté des pages à pas mal d’endroits. Les chapitres les plus intéressants sont à la fin. Chacun a un résumé, fort utile pour gagner du temps, et des exercices, sans corrigé. Bref, bien que je n’ai jamais autrefois étudié la ”théorie” des bases de données et que je pense avoir appris quelques trucs, je ne sais pas si la substantifiques moelle de ce petit livre va décanter dans ma culture générale et me servir un jour, consciemment ou pas, ou si elle me servira juste à être pédant sur le distinguo entre tables et relations, ou à médire du SQL qui n’exprime pas toute la puissance du modèle relationnel. Il est tout de même sûr que les bases de données, comme tant d’autres choses, c’est d’abord un problème de sémantique. Je ne suis pas le seul à être partagé, ça se retrouve dans [les commentaires chez O’Reilly|http://shop.oreilly.com/product/9780596100124.do?sortby=publicationDate#PowerReview|en].