Attendez-moi, vous allez trop vite !
Envoyé par
J1
nous ne parlons donc plus ici de "simple" SQL, mais de SQL procédural, permettant de réaliser des boucles
Considérez-vous cet exemple comme du genre procédural ou déclaratif ?
A ce sujet, je cite Bertrand Russel :
The method of "postulating" what we want has many advantages; they are the same as the advantages of theft over honest toil.
Ce qui revient dans notre contexte à dire que la récursivité est à la programmation impérative ce que le vol est au labeur honnête...
Envoyé par
J1
Mais, en admettant que l'on opte effectivement pour la solution des lignes autoréférencées, on peut alors ajouter dans la condition de jointure que pk doit être différent de fk.
Quand je dis que je crains l’auto-référence, c’est parce que je suis distrait et que je pourrais oublier la condition de jointure que vous évoquez. Et même si j’y pense, certains de mes collègues moins aguerris ou vigilants pourraient tomber dans le piège.
Je cite say : "En tout logique la mise en place d'autoréférence doit s'accompagner de mise en place de contrainte interdisant la présence d'une valeur <x,x>."
Il est évident qu’il faut la jouer "Ceinture, bretelles et épingle à nourrice" et prendre le maximum de précautions en enrichissant la création de la table Test d’une contrainte c3, valant quel que soit le niveau de la hiérarchie :
1
2
3
4
5
6
| CREATE TABLE test (
pk NUMERIC,
fk NUMERIC,
CONSTRAINT c1 PRIMARY KEY (pk),
CONSTRAINT c2 FOREIGN KEY (fk) REFERENCES test (pk) ON DELETE CASCADE),
Constraint c3 check (pk <> fk); |
Envoyé par
J1
juste l'envie d'en savoir plus sur un thème que je n'avais pas encore eu l'occasion d'approfondir
Nous ferez-vous part de vos découvertes, notamment en ce qui concerne le comportement des autres SGBD ? Il y a certainement matière...
Envoyé par
J1
Je pense que ce fsmrel veut dire, c'est que si l'on imagine la table Personnes suivante :
1
2
3
4
| Nom NomDuSuperieur
-----------
Col.T Col.T
Col.H Col.T |
le colonel T et le colonel H sont tous deux considérés comment subordonnés du colonel T.
Pour éviter cela, l'autre solution envisageable serait donc :
1
2
3
4
| Nom NomDuSuperieur
-----------
Col.T NULL
Col.H Col.T |
Certes ! Mais...
Envoyé par
J1
le colonel T dirait-il qu'il n'a d'ordre à recevoir de personne (solution 2), ou dirait-il qu'il n'a d'autre maître que lui-même (solution 1) ?
La solution 1 engendrerait des situations intéressantes pour notre colonel, si par exemple il donnait l’instruction suivante : "Tous mes collaborateurs et leurs collaborateurs jusqu’au dernier seront d'astreinte dimanche prochain" (sous-entendu : "pendant que moi j'irai aux champignons)".
Envoyé par
J1
soit des lignes pour lesquelles la colonne fk n'est pas renseignée :
(dans ce cas, on définira évidemment la colonne fk comme étant nullable)
Fatalement, si l’on veut éviter l’auto-référence, on déboule sur l’utilisation de NULL. Or, vous savez que je suis partisan de coder "NOT NULL" pour chaque colonne de chaque table. C’est pour moi un défi et un enjeu, à savoir rester dans une logique binaire et éviter les pièges qui nous guettent dans l’emploi d’une logique ternaire inhérente à l’emploi de NULL.
Aussi, pour répondre à l’interrogation de say :
Envoyé par
say
Envoyé par
fsmrel
rétablir les choses (notamment au niveau du MCD).
c'est-à-dire? mettre de côté les relations réflexives, en omettant certaines de leurs avantages?
Loin de moi une telle idée !
Je vois plutôt les choses ainsi :
Considérons les deux MCD suivants (AGL Power AMC)
(MCD).jpg)
MCD I et MCD II vont donner lieu respectivement à MLD I et MLD II
(MLD).jpg)
Observations :
Dans MCD I, la cardinalité 0,1 donne lieu dans MLD I à une colonne ChefId nullable. SI l’on préfère l’auto-référence, on remplace 0,1 par 1,1.
Dans MCD II, l’association-type Hierachiser est remplacée par une entité-type Hierarchie. La cardinalité 1,1 mise entre parenthèses exprime l’identification relative, ce qui se traduit dans MLD II par le fait que PsnId est clé primaire de la table Hierarchie.
Le DDL produit par AMC est le suivant (modifier le métabolisme de la table Hierarchie comme on l’entend (Cascade) et ajouter au besoin la contrainte HieC4).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| CREATE TABLE Personne (
PsnId Integer not null
, Nom Varchar(48) not null
, Fonction Char(48) not null
, Constraint PsnC1 PRIMARY KEY (PsnId)
);
CREATE TABLE Hierarchie (
PsnId Integer not null
, ChefId Integer not null
, Constraint HieC1 PRIMARY KEY (PsnId)
, Constraint HieC2 Foreign key (PsnId) References Personne
, Constraint HieC3 Foreign key (ChefId) References Personne
, Constraint HieC4 check (PsnId <> ChefId)
); |
Maintenant, si le directeur de projets est intransigeant et exige que la suppression d’une personne entraîne celle de ses collaborateurs, de leurs collaborateurs, jusqu’au dernier, avec MCD II il peut y avoir un léger problème d’adéquation de la programmation et du fonctionnel. Je soumets cela à votre sagacité. Rien n'est jamais acquis...
Relation réflexive avec mise à jour/suppression en cascade
Répondre avec citation
)
mais je pense que ce serait gérable.
Partager