To sidebar

mercredi 18 janvier 2017

Database In Depth (Relational Theory for Practitioners) (C.J. Date)

Database In Depth - C.J. DateVoilà un livre dont je ne sais quoi trop penser. La cible avouée de l’auteur : les professionnels qui ont besoin d’une bonne dose de rappel sur la théorie des bases de données relationnelles, et qu’on leur rappelle ou apprenne les limites du SQL.

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 » (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.

Ajouter un commentaire

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.

La discussion continue ailleurs

URL de rétrolien : https://www.coindeweb.net/blogelephant/index.php?trackback/4

Fil des commentaires de ce billet

© SQL & éléphant, after the WP Dusk To Dawn theme Propulsé par Dotclear