Discussion :

[kox2ee]

Bonjour,
Et félicitations pour Looping
Avec des airs de rien, plein d'humilité, Looping fait très bien ce que beaucoup d'autres ne font pas ou font moins bien, et en le faisant payer (cher) à l'utilisateur...

J'espère ne pas faire une demande déjà formulée (j'ai cherché sans trouver), donc je formule :

J'ai vu dans les options qu'il était possible de définir l'identifiant automatique (choix dans une liste entre Id_NomClasse et NomClasse_Id).

Personnellement, aucun des 2 ne me convient, le mélange des _ et des Majuscules (et oui, on a tous nos manies)
Généralement, je mets id sur toutes les entités, pour satisfaire les ORM.

Une configuration basée sur un masque par ex id{Nomclasse}, saisi par l'utilisateur donnerait plus de souplesse, pour cet élément important :
L'idéal serait qu'en plus, ce masque tienne compte de la casse :
Pour l'entité produit

• id{nomclasse} génère idproduit
• id{Nomclasse} génère idProduit
• id génère id

Et mettre le même principe sur le nommage des champs en clé étrangère serait aussi pas mal (avec mes id sur toutes les entités, j'ai des clés étrangères innommables pour l'instant) :
Le masque sur clé étrangère aurait besoin de 2 parties variables éventuelles : les noms de table et de champ auquels la clé fait référence
donc un masque du genre: {champRef}{tableRef}, avec la même prise en compte de la casse sur la première lettre :-)


De cette façon, tout le monde peut s'y retrouver...
Pour l'instant, les masques sont les suivants :

• identifiantAuto : Id{Nomclasse}
• fkAuto : {champRef}

Pour moi, ce serait plutôt :

• identifiantAuto : id
• fkAuto : id{TableRef}

Et chacun pourrait utiliser ses propres règles de nommage, satisfaisant ses besoins/normes/pratiques

[Paprick]

Bonjour,
Merci pour ces suggestions qui sont très intéressantes... Je promets de les étudier pour les prochaines versions .
En attendant, sachez que vous pouvez déjà utiliser vos propres normes/pratiques, d'une part en donnant le nom que vous voulez aux identifiants sans utiliser l'identifiant automatique (mais c'est vrai que ça prend plus de temps) et, d'autre part, pour les FK, en utilisant le libellé des rôles sur les pattes d'associations pour nommer comme les FK comme vous le souhaitez.

[kox2ee]

Merci de cette réponse !
J'utilise effectivement cette possibilité de renommage.
A noter que l'introduction de masques personnalisables pour l'identifiantAuto et les fkAuto va au delà de l'économie de renommages : elle participe également à l'uniformisation/normalisation des nommages utilisés dans un modèle.

[kox2ee]

...d'autre part, pour les FK, en utilisant le libellé des rôles sur les pattes d'associations pour nommer comme les FK comme vous le souhaitez.

Bonsoir,
Je reviens sur cette partie de la réponse, et sur ce que j'ai dit :
Je n'ai vu aucun effet sur le MLD ou le script généré du nommage du rôle sur la patte de l'association



J'ai peut-être mal interprété la suggestion...

[Paprick]

Bonsoir,

Le rôle pris en compte pour le renommage ou le suffixage de la clé étrangère est celui de la patte 0,n : ça peut paraître bizarre au premier abord mais c'est logique quand on approfondit bien le raisonnement !
En effet, la clé étrangère provient de la classe d'entités côté patte 0,n : c'est donc là que le rôle doit être défini.
Pour vous en convaincre, réalisez une association ternaire avec 2 pattes 0,n et 1 patte 1,1 : si vous voulez renommer les clés étrangères, vous verrez vite que vous n'avez as le choix .
Idem dans le cas d'une association 0,n /0,n : il faut bien pouvoir renommer les clés étrangères constituant la clé primaire de la table d'association ; d'ailleurs, décomposez avec Looping cette association, et tout sera encore plus limpide !

[kox2ee]

Oui, c'est tout à fait logique,
je me suis laissé embarquer dans une vision anglo-saxone du role, dans un MEA !
Ce qui m'a également conduit à ne pas bien nommer le role (facture n'a pas de sens).

Je rectifie



Merci !
beaucoup

PS : Ceci dit, dans une approche Merise, j'ai quand même la tentation de mettre ce idClient près de la cardinalité 1,1 du côté de la facture.
Ce sont les anglo-saxons qui inversent tout, pas nous ;-)
Mais ce n'est qu'une question de convention, à propos d'un concept qui n'est pas initialement merisien.

[escartefigue]

Bonjour,

Une méthode que j'utilise quand je ne suis pas contraint par les normes du client est la suivante : affecter un préfixe à chaque type d'entité et à chaque type d'association de cardinalité n (celles qui deviennent des tables donc). Ce préfixe est unique, codé sur 2 à 3 caractères selon la richesse du modèle.

L'avantage est qu'on retrouve très facilement l'origine des FK grâce à ce préfixe et que toute étude d'impact est également facilitée.

Le seul cas où j'utilise le rôle sur une patte de l'association est celui des assos reflexives type parent/enfant ou composant/composé

Exemple :
Pièce jointe 598662

Qui donne le script suivant (ici pour SQL server) :

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
CREATE TABLE CL_client(
   CL_id INT IDENTITY,
   CL_nom VARCHAR(50) NOT NULL,
   CL_datecrea DATE NOT NULL,
   PRIMARY KEY(CL_id)
);
 
CREATE TABLE FA_facture(
   FA_ident INT IDENTITY,
   FA_date DATE NOT NULL,
   CL_id INT NOT NULL,
   PRIMARY KEY(FA_ident),
   FOREIGN KEY(CL_id) REFERENCES CL_client(CL_id)
);

[fsmrel]

Ave,
 
 

Une méthode que j'utilise quand je ne suis pas contraint par les normes du client est la suivante : affecter un préfixe à chaque type d'entité et à chaque type d'association de cardinalité n (celles qui deviennent des tables donc). Ce préfixe est unique, codé sur 2 à 3 caractères selon la richesse du modèle.

L'avantage est qu'on retrouve très facilement l'origine des FK grâce à ce préfixe et que toute étude d'impact est également facilitée.

Le seul cas où j'utilise le rôle sur une patte de l'association est celui des assos reflexives type parent/enfant ou composant/composé

Exemple :
Pièce jointe 598662

Qui donne le script suivant (ici pour SQL server) :

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
CREATE TABLE CL_client(
   CL_id INT IDENTITY,
   CL_nom VARCHAR(50) NOT NULL,
   CL_datecrea DATE NOT NULL,
   PRIMARY KEY(CL_id)
);
 
CREATE TABLE FA_facture(
   FA_ident INT IDENTITY,
   FA_date DATE NOT NULL,
   CL_id INT NOT NULL,
   PRIMARY KEY(FA_ident),
   FOREIGN KEY(CL_id) REFERENCES CL_client(CL_id)
);

 
 
Capitaine, ton mcd ne s’affiche plus (la pièce jointe a disparu).
J’estime que pour des gens sérieux et dévoués comme toi, DVP devrait ne pas limiter le nombre de pièces jointes, toujours fort utiles.

A défaut, je pourrais la copier chez moi (hors DVP), je n’ai pas de problème de limite d’affichage.

[escartefigue]

Je plaide coupable : j'avais il y a plusieurs mois fait du ménage dans mon profil perso (une alerte me disait que j'étais en limite de capacité) en supprimant notamment des pièces jointes, pensant -à tort - que ça n'impactait pas les messages publiés.
J'ai rétabli quelques images perdues, mais pour d'autres, je ne peux plus le faire, car malheureusement, j'ai aussi égaré ma clef USB dans laquelle je stockais un grand nombre de MCD, dont ceux de DVP.