Discussion :

[escartefigue]

Merci pour la réponse. Je ne connaissais pas la syntaxe SELECT INTO, mais c'est bien pratique ! Par contre, en faisant

Code sql :

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

1
2
3
4
5
DECLARE @idsubmitter int
SELECT id_user 
INTO @idsubmitter
FROM   user_table 
WHERE sesa = 12345

, erreur SQL. Qu'est-ce qui ne va pas ?

Sans le message d'erreur, exact difficile à dire...
Est-ce que SESA est bien une colonne de type numérique ? Sinon il faut encadrer la valeur par des quotes simples (apostrophes)

Bonjour,

A la vue des discussions il apparait clairement que le modèle n'est pas encore abouti…

Par exemple :

• Il y a des discussions concernant les notions de 'custumer' et de 'submitter' mais ces concepts n'apparaissent même pas sur le MCD !

• Il y a surement beaucoup de questions, pas encore posées, qui attentent des réponses !
  - un 'submitter' peut-il posséder une une licence ?
  - la 'Company', définie 'en vrac' au niveau de l'utilisateur (custumer, submitter ou les 2 à la fois'), ne sera-t-elle pas un objet de gestion à sortir du USER ?
  - on perçoit que la notion de rôles de l'utilisateur (et peut-être même de la 'Company...) doit être creusée
  -...

Le fait que l'on tolère autant de NULL dans votre DDL est également un marqueur de réflexion non encore aboutie...

Certains des points évoqués ci-dessus ont déjà été abordés dans l'autre fil de discussion justement consacré à la modélisation

Les notions de id_customer et de id_submitter, sont présentes dans le MCD sous la forme de FK de la table ticket vers la table user_table.

Plus précisemment, il n'y a pas de notion de table ni de FK au niveau conceptuel, elles n'apparaissent que dans le modèle tabulaire (MLD et MPD).
Cela étant, les unes comme les autres sont les conséquences directes du MCD

Déjà, comment voyez-vous que des NULL sont autorisés ? S'agit-il de toutes les colonnes sans NOT NULL ?

S'il n'est pas mentionné explicitement "not null" alors les nulls sont autorisés, sauf si la colonne (ou le groupe de colonnes) est déclarée comme PK qui, par définition est "not null".

[isabelle.letrong]

Les notions de id_customer et de id_submitter, sont présentes dans le MCD sous la forme de FK de la table ticket vers la table user_table.

Quand vous parlez de FK, on se situe au niveau du MLD et non du MCD.

La notion de 'custumer' qui semble être un rôle particulier accordé à un 'user' doit être définie formellement, autrement que comme une clé étrangère dans une table, idem au niveau du submitter.
Bref, dans votre MCD il faut un rond ou un rectangle pour matérialiser un submitter ou custumer . Le fait que cela soit un rond (association) ou un rectangle devra être fait au regard de ce que sont les submitter ou custumer (simple association ou objets de gestion ?).

Sortir company, comme buunitname et organization de user_table aurait pour conséquence de rajouter l'existence de 3 tables, ce qui alourdirait le modèle...

Le problème n'est pas d'alourdir le modèle (vous n'avez peut-être pas idée de la puissance d'un moteur relationnel et de la puissance de l'algèbre relationnelle) mais de traduire dans le modèle les règles applicables.
Par exemple, je comprends que 'company' soit celle d'un custumer, mais est-elle aussi toujours celle d'un user 'submitter'. En d'autre termes, company a-t-il bien place dans le user ? Non, s'il est uniquement une donnée liée à un custumer. Et par ailleurs comment ferez vous dès que vous allez chercher à savoir le nombre de tickets émis par une 'company' (SNCF, S.N.C.F, ...)
Remplir des tables avec une liste de colonnes pouvant être null, sous-couvert de faire un modèle léger, est une aberration vis à vis du modèle relationnel et vous posera des problèmes, sur le plan des performances et dès que vous voudrez faire évoluer l'application ...

Déjà, comment voyez-vous que des NULL sont autorisés ?

Parce que tout ce qui n'est pas explicitement précisé comme 'NOT NULL' est considéré comme 'DEFAULT NULL'

[laurentSc]

Sans le message d'erreur, exact difficile à dire...
Est-ce que SESA est bien une colonne de type numérique ? Sinon il faut encadrer la valeur par des quotes simples (apostrophes)

Je n'ai pas mis le message car il ne nous apprend rien :

Error Code: 1064. You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near DECLARE @idsubmitter int SELECT id_user INTO @idsubmitter FROM user_table W' at line 1

Mais j'ai remarqué que ça vient de la ligne DECLAREcar si je l'enlève, il n'y a plus d'erreur...

La colonne sesa est bien numérique :

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CREATE TABLE user_table(
   id_user INT AUTO_INCREMENT,
   sesa INT NOT NULL,
   firstname VARCHAR(255),
   lastname VARCHAR(255),
   email VARCHAR(255),
   company VARCHAR(50),
   buunitname VARCHAR(50),
   organization VARCHAR(50),
   id_user_manager INT,
   id_location INT NOT NULL,
   PRIMARY KEY(id_user),
   UNIQUE(sesa),
   FOREIGN KEY(id_user_manager) REFERENCES user_table(id_user),
   FOREIGN KEY(id_location) REFERENCES location(id_location)
);

Quand vous parlez de FK, on se situe au niveau du MLD et non du MCD.

Je le savais mais ça me paraissait plus clair d'employer ce terme. Qu'aurait-il fallu dire pour un MCD (attribut d'une relation ?)

Par exemple, je comprends que 'company' soit celle d'un custumer, mais est-elle aussi toujours celle d'un user 'submitter'. En d'autre termes, company a-t-il bien place dans le user ?

En fait, la company n'est non seulement pas celle d'un submitter mais même pas non plus celle d'un customer ! Car si on retourne à mon MCD (celui du post #1), on voit qu'il y aussi des propriétaires de licence et il n'y a qu'eux qui ont une company. Je crois que je vais remplacer la table user_table par 3 tables : license_owner, customer et submitter. En outre, organization ne concerne que les customer et buunitname que les license_owners. Et comme ça, il y aura plus de NOT NULL . Sauf que avec Roland-Garros à la télé, je suis moins performant .

[escartefigue]

Je n'ai pas mis le message car il ne nous apprend rien : Mais j'ai remarqué que ça vient de la ligne DECLAREcar si je l'enlève, il n'y a plus d'erreur...

Je n'y avais pas prêté attention, mais il manque tout simplement un point-virgule entre la déclaration de la variable et la requête

[laurentSc]

Vous êtes sûr ? Car si je mets juste la déclaration de la variable, point-virgule ou pas, l'erreur reste :
DECLARE @idsubmitter int ou DECLARE @idsubmitter int; même message d'erreur...

[Artemus24]

Salut à tous.

Vous devez encapsuler vos lignes dans une procédure stockée, sinon vous aurez des erreurs.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
drop procedure `trait`;
 
delimiter $$
create procedure `trait` ()
DETERMINISTIC
NO SQL
BEGIN
  DECLARE _submitter integer default null;
 
  SET _submitter = (SELECT `id_user` FROM `user_table` where `sesa`=12345);
 
  INSERT INTO `...` (`customer`) values (_submitter);
END$$
DELIMITER ;

@+

[laurentSc]

En effet, y a plus d'erreur. Néanmoins, malgré l'insert, il n'y a pas de nouvel enregistrement dans la table ticket

J'ai juste modifié la valeur pour en mettre une qui existe...

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
drop procedure `trait`;
 
delimiter $$
create procedure `trait` ()
DETERMINISTIC
NO SQL
BEGIN
  DECLARE _submitter integer default null;
 
  SET _submitter = (SELECT `id_user` FROM `user_table` where `sesa`=29353);  #1
 
  INSERT INTO `ticket` (`id_submitter`) values (_submitter);
END$$
DELIMITER ;

EDIT : je ne connais pas du tout les procédures stockées.

[Artemus24]

Salut laurentSc.

Il faut exécuter la procédure en faisant un :

Code :

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

call `trait` ();

@+

[laurentSc]

[isabelle.letrong]

laurentSc, quelques remarques concernant votre procédure stockée

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
drop procedure `trait`;
 
delimiter $$
create procedure `trait` ()
DETERMINISTIC
NO SQL
BEGIN
  DECLARE _submitter integer default null;
 
  SET _submitter = (SELECT `id_user` FROM `user_table` where `sesa`=29353);  #1
 
  INSERT INTO `ticket` (`id_submitter`) values (_submitter);
END$$
DELIMITER ;

• Votre procédure n'a rien de DETERMINISTIC : la valeur de 'id_user' peut théoriquement varier en fonction de 'sesa'. Si vous mettez DETERMINISTIC MySQL ira chercher dans son cache le résultat de cette requête si elle a déjà été exécutée, sans effectuer de nouveau la requête.

• Votre procédure contient, pour le moins, du SQL. le mot clé à utiliser est : 'MODIFIES SQL DATA' et non 'NO SQL' !

• Vous pouvez juste utiliser un insert sans utiliser de variable intermédiaire :
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
   
  delimiter $$
  create procedure `trait` ()
  DETERMINISTIC
  NO SQL
  BEGIN
     INSERT INTO 	`ticket`
  		(`id_submitter`)
  	SELECT	`id_user`
  	FROM 	`user_table`
  	WHERE 	`sesa`= 29353	;
  END
  $$

  Evidemment, le mieux est de passer '29353' à la procédure en paramètre IN

• Par ailleurs un paramètre OUT de statut pourrait vous retourner un cr d'exécution de la procédure car MySQL peut lever une exception ou une erreur sur le INSERT qu'il faut savoir gérer et ce, probablement dans un cadre transactionnel!

[laurentSc]

Merci. Votre procédure marche. J'ai essayé de passer le sesa en IN :

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
delimiter $$
create procedure `trait` (IN sesa INT)
DETERMINISTIC
NO SQL
BEGIN
   INSERT INTO 	`ticket`
		(`id_submitter`)
	SELECT	`id_user`
	FROM 	`user_table`
	WHERE 	`sesa`= sesa	;
END
$$
call `trait`(29353)

mais la clause WHERE n'est pas prise en compte. Aujourd'hui, la table user_table comporte 3 enregistrements et l'appel à la procédure rajoute 3 lignes à ticket...Je pense que le passage de paramètre IN est mauvais. Comment aurait-il fallu faire ?

[laurentSc]

Je crois que je vais remplacer la table user_table par 3 tables : license_owner, customer et submitter. En outre, organization ne concerne que les customer et buunitname que les license_owners.

C'est fait ! Comme je ne connais pas encore le mécanisme d'héritage dans les MCDs, bien que les 3 classes
license_owner, customer et submitter possèdent une partie commune et que donc il aurait fallu créer une classe mère et 3 classes filles, j'ai simplement créer une 4e classe user_table et les 3 classes citées ci-dessus lui sont reliées.

Ca n'est pas hyper lisible, mais on fait ce qu'on peut :

[escartefigue]

Attention à ne pas mettre la charrue avant les boeufs, la stabilisation du modèle de données, en tout cas de son socle, sa partie "coeur de métier", est un pré-requis à la réalisation des traitements.

Il serait plus prudent de faire avancer l'autre fil de discussion relatif au modèle de données avant de se préoccuper des triggers, procédures stockées et autres requêtes.

[isabelle.letrong]

Il serait plus prudent de faire avancer l'autre fil de discussion relatif au modèle de données avant de se préoccuper des triggers, procédures stockées et autres requêtes.

J'ai l'impression que laurentSc poursuit la réflexion sur le MCD dans ce fil de discussion..

Ceci étant, en regardant la nouvelle mouture :

• L'association 'licence_owner' avec le 'user_(table)' ne devrait-elle pas être plutôt avec le 'customer' ?

• id_customer et id_submitter ne doivent pas être auto-incrémentée car elles héritent de l'id_user. Du reste pour une meilleur compréhension vous pourriez appeler ces colonnes 'id_user'.

• Pour 'country', vous devriez utiliser la codification ISO 3166-1 alpha-3 (pas en tant qu'identifiant où il convient de rester sur un entier auto-incrémenté mais comme attribut ayant une propriété d'unicité).

[isabelle.letrong]

id_customer et id_submitter ne doivent pas être auto-incrémentée car elles héritent de l'id_user. Du reste pour une meilleur compréhension vous pourriez appeler ces colonnes 'id_user'.

Du coup, en toute rigueur, ce ne sont pas des associations entre user_table et customer ainsi qu'entre user_table et submitter mais des héritages (symbolisés par un triangle dans le MCD)

[escartefigue]

La discussion sur le modèle de données a repris dans le forum consacré, elle est ici :
https://www.developpez.net/forums/d2.../#post11730464

Il est préférable de s'en tenir là : discussion sur la modélisation des données dans le forum schéma ci-dessus et échanges sur les adaptations aux spécificités MySQL dans ce présent forum.
Ce sera plus clair pour tout le monde

Et comme il faut faire les choses dans l'ordre, attendons que le schéma soit à peu près stabilisé avant de s'intéresser à comment mettre en œuvre son utilisation sous MySQL