Discussion :

[fsmrel]

Je complète la réponse que j’ai faite sur le comportement de DB2 concernant le type DATE. Je fais à nouveau référence à DB2, mais la discussion vaut pour les autres SGBD, mutatis mutandis.

Je vous renvoie encore à :

DB2 Universal Database for z/OS, Version 8 - SQL Reference

Où il est précisé que si l’on code Not Null With Default pour une colonne de type DATE, mais sans préciser de valeur par défaut, alors DB2 fournira la date du jour (CURRENT DATE) lors des INSERT.

[fsmrel]

Il s’agit ici de savoir si les index sont des objets relevant de la norme SQL.

Je cite SQLpro :

Pour ce qui est des index comme des fichiers ce sont des problématique physiques. Or SQL est un langage d'objets logiques. Donc les index et fichiers n'existent pas dans la norme SQL.

Je confirme. Je dirais même que les tables sont les opérandes des opérateurs mathématiques Restriction, Projection, Jointure, Union, Intersection et compagnie. Autrement dit, ce sont nécessairement des êtres mathématiques dont la manipulation permet de produire de nouveaux êtres mathématiques, en conformité avec le principe de fermeture (le résultat du mariage de deux tables est une table et la récursivité peut jouer, de façon arbitrairement complexe). En revanche, je ne sache pas que nous disposions d’une algèbre d’index, lesquels ressortissent à un autre univers, disons le modèle physique de données.

A l’instar du Modèle Relationnel de Données, la norme SQL n’a donc pas à se préoccuper des index, lesquels ne sont vraiment pas de son ressort et relèvent plutôt de la performance des bases de données, donc directement des SGBD, à l'étage physique.


Je cite Eric93 :

Pour les fichiers ok, pour les index, je suis absolument pas d'accord, ou tu as vu que SQL est un langage d'objet logique ? Et même si c'étais le cas, quand on passe au modèle physique il faut bien prendre en compte les index, je ne connais aucun SGDB relationnel s'appuyant sur SQL qui n'utilise pas d'index.

En relation avec ce qui précède, on peut dire que vous confondez le niveau logique, relevant de la norme SQL, et le niveau physique, technologique, relevant directement de chaque SGBD et très fluctuant dans le temps, au gré des besoins et des innovations technologiques. Vous raisonnez DB2, parce que vous y trouvez l’instruction CREATE INDEX dans le SQL Reference de ce SGBD, mais qui vous dit que les paramètres de cette instruction sont pérennes ? Par exemple, on n’y trouve plus le paramètre SUBPAGES qui a été supprimé du jour où sont arrivés les index de type 2. Qui vous dit que les autres paramètres méritent de faire l’objet d’une norme et concernent donc les autres SGBD ? Qui vous dit que l’instruction CREATE INDEX elle-même ne disparaîtra pas un jour, parce que l’on aura trouvé nettement mieux pour booster les performances et qu’elle sera devenue sans objet ? Il serait vain, voire dangereux d’intégrer l’instruction CREATE INDEX à la norme.

Les éditeurs de SGBD sont convenus qu’il était sage d’adhérer à une norme relative au typage, à la structure des tables, les opérateurs pour les manipuler et les contraintes permettant d’en garantir l’intégrité : tout ce qui relève du composant RDS de DB2. Concernant le niveau physique, chacun doit pouvoir être libre de faire comme il l’entend. Tous les éditeurs proposent une instruction CREATE INDEX, mais les index ne sont pas forcément systématiquement des arbres B+ (ce que sont les index de DB2). Que voulez-vous imposer comme normes au niveau physique ? Et même, en supposant que l’instruction CREATE INDEX soit intégrée à la norme, pourquoi ne pas incorporer les instructions (non nécessairement typiques de DB2) CREATE CLUSTER, CREATE DIMENSION, CREATE STOGROUP (laquelle ne concerne guère les SGBD autres que DB2), CREATE WRAPPER (utilisée en DB2, mais pas dans sa déclinaison z/OS), etc. ? La totale, quoi. Avec à la clé une norme de 20000 pages, complètement instable et rapidement obsolète...
Les table spaces et les index sont là, les premiers pour assurer la persistance des données, les seconds pour permettre d’accéder plus rapidement à celles-ci. A la limite les VSAM LDS accueillant table spaces et index dans DB2 pourraient être jaloux de ne pas faire partie de SQL.
Maintenant, qui nous dit que les index ne partiront pas un jour dans les poubelles de l’Histoire ? C’est un peu comme le rôle joué par le charbon dans les transports ferroviaires ou celui de la voile pour le transport du fret maritime. Aujourd’hui, c’est fini. Un jour sans doute, les DBA auront oublié le mot 'index' lui-même, car la technologie aura bien évolué. Pour leur part, les tables vivront ce que vivent les mathématiques, à moins que la théorie relationnelle soit assassinée et qu’on en revienne à l’âge de la pierre.

[SQLpro]

Salut fsmrel.

J'avais pas le temps de mettre en termes aussi élégant ces concepts, car je donne formation sur formation en ce moment, notamment pour France telecom, le CEA et d'autres grand comptes... Et je bosse aussi le soir pour la révision de mon bouquin sur SQL et les week end pour mes clients locaux.

Je te remercie donc d'avoir remis en place les choses et d'y avoir pris le temps.

Un de ces jours il faudrait que nous fassions un livre sur la modélisation de données. Toi au sens théorique, moi au sens pratique !

A +

[fsmrel]

Un de ces jours il faudrait que nous fassions un livre sur la modélisation de données. Toi au sens théorique, moi au sens pratique !

Why not? Il y a de quoi faire !