Bonsoir superviny,
Envoyé par
superviny
Et de fait dans la
doc je trouve ceci:
You cannot associate a trigger with a TEMPORARY table or a view.
Et malheureusement MySQL n'accepte pas non plus de mettre à jour directement depuis la vue...
Doc (extrait choisi) :
For a multiple-table updatable view, INSERT can work if it inserts into a single table. DELETE is not supported.
Vous confirmez hélas ! ce que j’avais écrit :
Envoyé par
fsmrel
Mais, en ce qui concerne les inserts, je ne sache pas que MySQL permette de déclarer des triggers sur des vues...
C'est donc un démenti de la prétendue complétude affirmée par les promoteurs de MySQL qui écrivent :
« 7. Des fonctions complètes de développement d’applications
L’une des raisons pour lesquelles MySQL est la base de données open source la plus populaire au monde est qu’elle est adaptée à tous les besoins de développement d’applications. Au sein de la base de données, on pourra bénéficier de procédures stockées, de déclencheurs, de fonctions, de vues, de curseurs, d’un SQL à la norme ANSI, etc. »
Nonobstant les allégations mysqlesques, vous serez donc contraint à faire respecter la contrainte de façon applicative...
Cela ne vous consolera pas, mais pour que vous mesuriez la distance qui sépare MySQL du Modèle Relationnel de Données (cela vaut du reste pour les autres SGBD SQL, sans oublier la norme elle-même...), voici pour résumer comment garantir la cardinalité 1,N en utilisant Tutorial D :
Déclaration des variables (cf. mon 1er message) :
Variable GROUPE :
1
2
3
4
5
6
7
|
VAR GROUPE BASE RELATION
{
GroupeId INTEGER,
GroupeNom CHAR
}
KEY {GroupeId} ; |
Variable PERSONNE :
1
2
3
4
5
6
7
|
VAR PERSONNE BASE RELATION
{
PersonneId INTEGER,
PersonneNom CHAR
}
KEY {PersonneId} ; |
Pour brancher les groupes et les personnes :
1
2
3
4
5
6
7
8
9
|
VAR PERSONNE_GROUPE BASE RELATION
{
GroupeId INTEGER,
PersonneId INTEGER
}
KEY {GroupeId, PersonneId}
FOREIGN KEY {GroupeId} REFERENCES GROUPE
FOREIGN KEY {PersonneId} REFERENCES PERSONNE ; |
Déclaration de la contrainte traduisant la règle selon laquelle :
Une personne appartient au moins à un groupe.
1
2
3
|
CONSTRAINT C001
PERSONNE {PersonneId} = PERSONNE_GROUPE {PersonneId} ; |
Venons-en à l’œuf de Christophe Colomb, c'est-à-dire à un principe très simple dont les auteurs de la norme SQL (abréviation de Sorry Query Language) n’ont même pas eu l’idée de s’inspirer... Tutorial D met à notre disposition l’affectation multiple, laquelle permet de regrouper en une seule instruction un nombre quelconque d’instructions élémentaires.
Dans le code, deux instructions sont élémentaires quand elles sont séparées par une virgule et la dernière de celles-ci suivie d’un point-virgule. Les contrôles faisant l’objet des contraintes ne sont déclenchés qu’à la détection du point-virgule, après à quoi l’utilisateur pourra reprendre le contrôle des opérations.
Mettons à jour simultanément les relvars PERSONNE et PERSONNE_GROUPE :
1
2
3
4
5
6
7
8
9
10
11
12
13
|
INSERT PERSONNE RELATION {TUPLE
{
PersonneId 1,
PersonneNom 'Raoul'
}
}, /* virgule : séparateur d’opérations */
INSERT PERSONNE_GROUPE RELATION {TUPLE
{
GroupeId 1,
PersonneId 1
}
} ; /* point-virgule : fin de la liste des opérations*/ |
Cette fois-ci la contrainte C001 ne verra rien à redire car la cardinalité 1,N est bien place, Raoul fait bien partie d’un groupe.
On n’a pas eu besoin de se creuser les méninges et en passer par des palliatifs plus ou moins tarabiscotés...
TRADUCTION RELATION (1,n)--(0,n)
Répondre avec citation
)
Partager