Bonsoir,
Envoyé par
StringBuilder
Je vois pas trop en quoi, si MySQL traite séquentiellement les lignes (seule explication rationnelle au message de clé dupliquée), peut être qualifié d'ensembliste.
Ce comportement est la preuve que MySQL ne fait pas de l'algèbre ensembliste, mais des traitements séquentiels.
Vous mélangez le niveau logique du langage, qui fait l’objet de la 5e des 12 règles de Codd et le niveau physique qui fait l’objet de la 8e règle.
L’algèbre relationnelle (ensembliste par définition du modèle relationnel de données de Codd) concerne le niveau logique. Au niveau physique, les SGBD relationnels font ce qu’ils veulent, c’est sous le capot : qu’ils y pratiquent les méthodes d’accès les plus simples (séquentielle par exemple) ou les plus sophistiquées n’a rien à voir avec l’algèbre, et leur demander de pratiquer celle-ci sous le capot : certainement pas.
Ainsi, quand vous dites que MySQL traite séquentiellement les lignes, vous le jugez de facto au niveau physique, et si la méthode dont ce SGBD se sert pour y gérer ses fichiers est séquentielle, on peut le conjecturer, mais sans prétendre le jurer, à moins d’en avoir la confirmation par une analyse serrée de leur code source.
Reprenons l’exemple de SQLpro : UPDATE T_UNIK SET C = C + 1;
Sous le capot, toutes les tactiques sont permises :
Par exemple, partant de l’ensemble {1,2 ,3}, au niveau de la cuisine physique, produire séquentiellement un sac du genre : (2, 2, 3, 3, 4) puis dédoublonner, et finalement présenter au niveau logique un ensemble : {2, 3, 4}, pas de problème, c’est le résultat que j’attends moi aussi.
Cela dit, dans leur tambouille interne, MySQL et PostgreSQL procèdent manifestement autrement, de façon certes (trop) fruste, en déclenchant une erreur à la détection d’un doublon à l’occasion de l’opération d’addition, mais l’ensemble initial {1,2 ,3} n’a pas été remplacé : intuitons que ces SGBD sont feignants sous le capot, mais que dire de plus ? En tout cas, qu’on soit déçu ou satisfait {1,2 ,3} est bien un ensemble, au niveau logique on ne peut que le reconnaître.
Envoyé par
StringBuilder
Il serait amusant de voir ce que ça donne avec la même requête qui fait -1 au lieu de +1, avec un peu de pot, MySQL ne va pas planter...
De fait, si on exécute une instruction en ce sens, on constate que MySQL et PostgreSQL fournissent le résultat que vous attendez : la conclusion que l’on peut tirer est alors la suivante : avec ces SGBD l’opération n’est pas réversible, et ça, ça n’est pas bien du tout : vous êtes en droit de recommander à ceux qui en ont la charge d’améliorer leur moteur.
Incidemment, dans la série des comportements instables, on peut reprocher à MySQL et PostgreSQL de permettre de coder ceci, mais ils ne font que se conformer à la norme SQL ! :
MySQL :
select date('2015-03-31') + interval 2 month ;
select date('2015-03-31') + interval 1 month + interval 1 month ;
Ces deux instructions ne donnent pas précisément le même résultat (en revanche, les choses se passent mieux si on remplace mars par juillet...) J’ai assisté en direct à une grosse colère de Chris Date à ce sujet...
PostgreSQL, même comportement instable :
select date('2015-03-31') + interval '2 months' ;
select date('2015-03-31') + interval '1 month' + interval '1 month' ;
Pour sa part, SQL Server ne tombe pas dans le panneau : No SQL Standard INTERVAL operation support.
Il faut vraiment le vouloir pour le pousser à l’instabilité :
select dateadd(month, 2, '2015-03-31') ;
select dateadd(month, 1, dateadd(month, 1,'2015-03-31')) ;
Envoyé par
SQLpro
Non désolé. Ce n'est pas une alternative... Relit Codd !
RÈGLE 7 - Insertion, suppression et modification ensemblistes :
Le SGBDR retourne un ensemble d’éléments en réponse aux requêtes qui lui sont soumises. Il doit pouvoir mettre à jour un ensemble d'éléments en exécutant une seule requête.
Ne t’inquiète pas. J’ai assisté à la présentation faite par Codd lui-même au palais des congrès, à Paris en 1987. Il a planché le 29 septembre, et j’ai attentivement suivi tout ce qu’il a dit notamment à propos des 12 règles.
A cette occasion, voici l’énoncé exact qu’il a donné de la règle 7 :
The capability of handling a base relation or a derived relation as a single operand applies not only to the retrieval of data but also to the insertion, update, and deletion of data.
Il n’a rien dit sur l’isolation des transactions en relation avec cette règle.
Envoyé par
SQLpro
Autrement dit, la transaction fait passer les données d'un ensemble d'un état A à un état B en masquant au autres utilisateurs les incohérences transitoires potentielles. C'est la notion même d’isolation des transactions !
A ton tour de bien relire Codd... Tu fais donc référence non pas à la règle 7, mais à la règle 5 (Comprehensive Data Sublanguage Rule) :
A relational system may support several languages and various modes of terminal use (for example, the fill-in-blanks mode). However, there must be at least one language (1) whose statements are expressible per some well-defined syntax, as character strings; and (2) which is comprehensive in supporting ALL of the following items:
1 data definition
2 view definition
3 data manipulation (interactive & by program)
4 integrity constraints
5 authorization
6 transaction boundaries (begin, commit, and rollback).
A propos du point 6, je cite C.J. Date (Relational Database Writings, 1989-1991) :
« If we are going to include operation such as BEGIN TRANSACTION (etc.), then what about concurrency control operations? What about load and unload operations? What about reorganization? Auditing? Other functions? (etc., etc.) All of these items surely have as much—or a little—right to be included as do BEGIN TRANSACTION, COMMIT, etc. in a list of “relational” requirements. (My point, in case it is not obvious, is that such matters are really nothing to do with the question of wheter a given DBMS qualifies as relational or not.) »
Autrement dit, la théorie relationnelle n’a rien à voir avec cette histoire d’isolation, qui concerne en réalité tout SGBD, qu’il soit relationnel ou non, mais sous le capot (règle 8).
Partager