Discussion :

[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.

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

[SQLpro]

Maintenant, si tu préfères que le résultat soit :

C
--
2
3
4

Alors, bien entendu, pourquoi pas cette alternative,

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.

"

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 +

[fsmrel]

Bonsoir,

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.

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')) ;

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.

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).

[escartefigue]

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).

En effet, cela dit, les SGBD R sont bien heureusement mieux lotis que leurs ancêtres non relationnels sur ce chapitre

[SQLpro]

Au passage sur la problématique temporelle et le fait que la norme interdise des calculs temporels avec une granularité intermédiaire de mois, SQL Server de banane aussi.
Je donne toujours cet exemple dans tous mes cours :

Code :

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

SELECT DATEADD(month, -1, DATEADD(month, 1, CAST('2001-01-31' AS DATE)))

En principe : X + 1 - 1 = X...
Pour SQL Server dans ce cas, X = Y !

A +

[escartefigue]

Avec DB2 for Z/OS j'obtiens :

Code :

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

1
2
3
4
5
6
SELECT ADD_MONTHS('2001-01-31', -1),                   
       ADD_MONTHS(ADD_MONTHS('2001-01-31', -1), +1)    
FROM SYSIBM.SYSDUMMY1 ;                                
 
£1         £2        
2000-12-31 2001-01-31

X+1-1 = X

Ce qui nous ramène au sujet initial, et plaide en faveur de DB2

[SQLpro]

Avec DB2 for Z/OS j'obtiens :

Code :

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

1
2
3
4
5
6
SELECT ADD_MONTHS('2001-01-31', -1),                   
       ADD_MONTHS(ADD_MONTHS('2001-01-31', -1), +1)    
FROM SYSIBM.SYSDUMMY1 ;                                
 
£1         £2        
2000-12-31 2001-01-31

X+1-1 = X

Ce qui nous ramène au sujet initial, et plaide en faveur de DB2

Truand, tu l'as fait à l'envers.... Essaye donc :

Code :

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

1
2
3
SELECT ADD_MONTHS('2001-01-31', +1),                   
       ADD_MONTHS(ADD_MONTHS('2001-01-31', +1), -1)    
FROM SYSIBM.SYSDUMMY1 ;

A +

[escartefigue]

Truand, tu l'as fait à l'envers.... Essaye donc :

Code :

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

1
2
3
SELECT ADD_MONTHS('2001-01-31', +1),                   
       ADD_MONTHS(ADD_MONTHS('2001-01-31', +1), -1)    
FROM SYSIBM.SYSDUMMY1 ;

A +

£1 £2
2001-02-28 2001-01-31
***********************
Same player shoot again

[StringBuilder]

Bonsoir,

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.

Je pense que ce n'est pas moi qui confond, mais les développeurs de MySQL, qui, au contraire, ne masquent pas à la partie "logique" les contraintes "physiques".

Ainsi, ils traitent séquentiellement "physiquement" les lignes, et remontent l'information au niveau logique, non pas de façon ensembliste (pour vérifier que l'état final est bon) mais bien séquentiellement (notification ligne à ligne) ce qui amène la partie "logique" à tester des contraintes sur un résultat intermédiaire, ce qui est totalement idiot (car inutile) et dangereux (provoque un comportement "non réversible", voir surtout hasardeux, car l'ordre physique des lignes dépend de nombreux facteurs, pas maîtrisés au niveau logique).

Une fois de plus, MySQL ne différencie pas la partie "logique" du SQL de la partie "physique" du stockage et des traitements. C'est pas moi qui fait l’amalgame.

[escartefigue]

Bonjour
Je souhaite établir le choix d'un SGBD pour une compagnie d'assurance dans le cadre de la refonte de son système d'informations.
La compagnie utilise le système DB2 comme surcouche de l'OS400 actuellement.
Elle dispose d'une Mainframe IBM.
Le choix de migrer vers un outil du marché (en Dotnet ou en JEE) est déjà acté mais je manque d'arguments pour les dissuader de l'utilisation du DB2 comme SGBD.
etc...

Le choix a -t- il finalement été fait ? si oui qu'en est il ?

[freestyler]

J'ai cru que la discussion n'allait pas s'arrêter d'où ma non contribution.

En fait, le choix s'est fait en décembre (ou plutôt ne s'est fait qu'en décembre).
Nous avons opté pour du SQL Server. Pour un mix de critères (financier, RH, attractivité de la DSI au marché de l'emploi, ...)
Je suis quand même encore sur ma faim en termes de comparaison

[escartefigue]

OK merci pour cette info
Je suppose que la base de donnée en question ne concerne pas le corps de métier donc ?

[SQLpro]

Nous avons opté pour du SQL Server. Pour un mix de critères (financier, RH, attractivité de la DSI au marché de l'emploi, ...)
Je suis quand même encore sur ma faim en termes de comparaison

Personelement j'ai fait ce choix en 1999.... À l'époque je travaillais sur une quinzaine de SGBDR : DBase, paradox, FoxPro, Access, Gupta SQL, Informix, Watcom, Ingres, Oracle, DB2, Sybase, MS SQL Server, Interbase, PostGreSQL...
Depuis, je n'ai jamais trouvé plus intéressant dans aucune des critères suivants :

• facilité
• sécurité
• robustesse
• performpances
• fiabilité
• respect des normes SQL
• coût global d’exploitation

Pour information, voici la dernière notation du gartner group au sujet des SGBD relationnels :
http://www.datastax.com/gartner-magic-quadrant-odbms
et le graphique de positionnement du "magic quadrant" :


A +