Discussion :

[kox2ee]

Pour ma part, je n’arrive pas à m’y faire et j’en viens à souvent proférer des gros jurons . Je verrais bien un mode de fonctionnement à la µsoft WORD, c’est-à-dire utilisation de la roulette + touche « CTRL ». Vos avis ?

Bonjour,

La roulette a un comportement attendu :

• Si le défilement/déplacement est possible (contenu + grand que contenant et donc présence de barres de défilement), la roulette provoque le défilement
• Si le défilement est impossible (sur une carte par exemple), la roulette provoque le Zoom/dé-Zoom
• Si le défilement est possible, mais qu'on souhaite zoomer, l'un des standards est le CTRL+roulette dont µsoft n'est pas l'inventeur (il est utilisé dans les navigateurs, les IDE, les éditeurs de documents...)

Il serait dommage de ne pas respecter ce standard :

• Roulette = déplacement
• CTRL+Roulette = Zoom

Parce que c'est un standard (et nous en connaissons tous l'importance - du respect des standards -), et qu'il serait facheux de perturber les utilisateurs conditionnés que nous sommes :-)

Sinon, la touche "0" du clavier est particulièrement appréciable pour repositionner et ajuster la taille d'un modèle à la fenêtre !

[Paprick]

Bonjour,

Bonjour,
Il serait dommage de ne pas respecter ce standard :

• Roulette = déplacement
• CTRL+Roulette = Zoom

Le problème de ce "standard" (qui ne l'est pas pour tout le monde ), c'est que le déplacement avec roulette n'est que vertical... or, nos modèles, comme en cartographie, s'étalent tout autant, voire plus, sur la largeur... et là pas de roulette pour se déplacer (sauf peut-être avec des supers souris de gamers !).
C'est pour cela que Looping propose le clic droit enfoncé pour déplacer le modèle dans tous les sens .
Après, faut-il imposer le "Ctrl" pour zoomer/dézoomer ? Je n'en suis pas convaincu ...
Je vais voir si ça peut se mettre en option...

[fsmrel]

Pour ma part, je n’arrive pas à m’y faire et j’en viens à souvent proférer des gros jurons . Je verrais bien un mode de fonctionnement à la µsoft WORD, c’est-à-dire utilisation de la roulette + touche « CTRL ».

Je n’arrive toujours pas à m’y faire et je passe mon temps à dézoomer ce que j’ai zoomé contre ma volonté et ça finit par me faire perdre le fil de mes idées…

[Paprick]

Je n’arrive toujours pas à m’y faire et je passe mon temps à dézoomer ce que j’ai zoomé contre ma volonté et ça finit par me faire perdre le fil de mes idées…

Allez, arrête de râler : dans la prochaine version, je vais le mettre en option ton CTRL !

[fsmrel]

Grand merci, Paprick

[escartefigue]

Je n’arrive toujours pas à m’y faire et je passe mon temps à dézoomer ce que j’ai zoomé contre ma volonté et ça finit par me faire perdre le fil de mes idées…

J'avoue n'être pas plus conciliant, sur ce point.
Merci Paprick pour ta bienveillance envers les récalcitrants que nous sommes

[laurentSc]

Bonjour,

Une autre évolution qui améliorerait l'ergonomie de cet outil génial : quand on génère un MCD, l'outil crée en parallèle le script SQL de la création de la bdd. Ce qui serait pratique, c'est que la création des tables soit faite dans l'ordre alphabétique des noms de tables car aujourd'hui, je n'ai pas saisi la logique et quand je cherche la création d'une table donnée, je ne sais pas où est le script...

[Paprick]

Bonjour,

Une autre évolution qui améliorerait l'ergonomie de cet outil génial : quand on génère un MCD, l'outil crée en parallèle le script SQL de la création de la bdd. Ce qui serait pratique, c'est que la création des tables soit faite dans l'ordre alphabétique des noms de tables car aujourd'hui, je n'ai pas saisi la logique et quand je cherche la création d'une table donnée, je ne sais pas où est le script...

Surtout pas !
Les tables doivent être créées dans un ordre bien déterminé qui permet à un CREATE TABLE de faire référence, pour les FK, à une autre table qui doit forcément avoir été créée avant.

[fsmrel]

Surtout pas !
Les tables doivent être créées dans un ordre bien déterminé qui permet à un CREATE TABLE de faire référence, pour les FK, à une autre table qui doit forcément avoir été créée avant.

Laurent, méditez bien ce qu’écrit Paprick, qui a bien sût totalement raison. Si vous utilisiez l’ordre alphabétique, les clés étrangères devraient être déclarées par ALTER TABLE après les CREATE TABLE, ce qui est possible, mais plutôt pénible et agaçant pour les adeptes du relationnel. Pour ma part, j’ai pratiqué avec bonheur et sans état d'âme la même méthode que Paprick pour des bases de données de plus de mille tables !

[laurentSc]

Surtout pas !
Les tables doivent être créées dans un ordre bien déterminé qui permet à un CREATE TABLE de faire référence, pour les FK, à une autre table qui doit forcément avoir été créée avant.

Maintenant que vous le dites, ça me paraît évident !

Pour ma part, j’ai pratiqué avec bonheur et sans état d'âme la même méthode que Paprick pour des bases de données de plus de mille tables!

Moi, je suis déjà perdu avec un modèle qui compte 12 tables...Comment arrivez-vous à vous y retrouver ?

[escartefigue]

Paprick a évidemment raison, qui plus est, tout SGBD relationnel dispose d'un catalogue qu'on peut interroger par SQL, un simple SELECT sur la table des tables trié par nom répond au besoin

[laurentSc]

Autre point ; ce n'est pas une proposition car je pensais à une amélioration et ça existe déjà !

Génial

Si on veut sélectionner une seule partie du modèle (par exemple pour déplacer un bloc de plusieurs classes avec des associations et des liens), on clique dans un coin en haut à gauche, puis on maintient appuyé le clic gauche de la souris et on va avec la souris dans un coin plus bas et à droite : ça sélectionne tous les objets qui appartiennent au rectangle qu'on vient de parcourir (identique aux logiciels de graphisme comme GIMP).

[fsmrel]

Je suis déjà perdu avec un modèle qui compte 12 tables...Comment arrivez-vous à vous y retrouver ?

Quand j’écris que j’au eu affaire à des bases de données de plus de mille tables, vous pouvez vous douter qu’il s’agit des données des entreprises, et que ces données recouvrent plusieurs domaines donnant lieu chacun à un référentiel (disons une vingtaine en tout) :

Référentiel Personnes, Contrats, Cotisations, Catalogue produits, Prospection de masse, Editique, etc.

Selon sa richesse, chaque domaine est à son tour à constituer en sous-domaines, au besoin chaque sous-domaine est constitué à son tour en sous-sous-domaines, etc.

En l’occurrence on a procédé à l’urbanisation des données.

Au niveau le plus fin, la représentation graphique doit tenir — de façon claire et lisible — sur un ensemble de pages au format (disons) A3, chaque page constituant une vue suffisante pour qu’un développeur s’y retrouve. Le mieux est qu’une page comporte de l’ordre de 7 entités-types (classes d’entités chez Paprick).

Pendant des décennies j’ai passé mon temps chez mes clients à m’assurer de la validité, de la clarté de leurs règles de gestion (en passant je vous renvoie à Nicolas Boileau : « Ce qui se conçoit bien, … », citation particulièrement chère à CinePhil, avec raison.
Combien ai-je martyrisé de chefs de projets pour qu’ils accouchent de dossiers de conception où les règles de gestion soient précises, dépourvues d’ambiguïté, non contradictoires, sans bavardage inutile (comme disait Albert, « Faites simple, mais pas plus simple »), aient du sens (cf. la proposition 7 du Tractatus de Wittgenstein : « Sur ce dont on ne peut pas parler, il faut garder le silence »). Ou encore comme disait Guillaume d’Ockham :

« Pluralitas non est ponenda sine necessitate » (Autrement dit, ce qui ne sert à rien : à dégager !)

En tout cas, Paris ne s’est pas fait en un jour, modéliser n’est pas inné, continuez à suivre les conseils de vos mentors et un jour vous ne serez plus désarçonné à la vue d’un MCD d’une douzaine d’entités-types…

Question à cent sous : que vous inspire le MCD ci-dessous ? Ne mériterait-il pas une certaine urbanisation et la production de dossiers de conception bien clairs ?

[escartefigue]

Au cas où, une petite bizarrerie que j'avais signalé dans cette discussion (réponse n° 83)
https://www.developpez.net/forums/d2...-d-entite-mcd/

et que je copie-colle ici

C'est curieux, car je viens de faire l'essai et ça fonctionne pour moi, aussi bien avec des asso devenant des tables que des FK héritées dans l'entité-type coté 1.

Par contre, j'ai trouvé un bug :

J'ai crée deux types
Pièce jointe 599543

J'attribue le premier type à l'identifiant de mon type d'entité, OK, j'ai bien le résultat attendu à la fois dans le type d'entité et dans l'association qui hérite de la colonne comme FK

Par contre, si je décide de remplacer dans le type d'entité le premier type par le deuxième, je n'y arrive pas, c'est systématiquement le premier qui revient
J'ai essayé de remplacer le type libre par un type counter et de refaire la manip inverse, rien n'y fait.
Deuxième tentative en inversant l'ordre des types libres prédéfinis :
Pièce jointe 599546

Et là, tout fonctionne

Etrange

À propos du nombre de tables, le client chez lequel j'interviens en ce moment a plus de 3000 tables cœur de métier.
Si on y ajoute les applications périphériques telles que la comptabilité, la gestion des incidents, la relation client, la RH on est bien au delà.
Evidemment, toutes ces tables sont dupliquées autant de fois qu'il y a d'environnement (prod, pré-prod, homol, recette, intégration, test unitaire) et de filière (homol 1, homol2, recette 1 etc.)
Heureusement, l'urbanisation est ici très bien conçue, toutes les tables ont un nom court (8 caractères) mais normé. Le nom seul permet de savoir à quelle brique et quartier appartient telle table, telle vue, tel index. Et çà c'est un vrai bonheur

[laurentSc]

Bonsoir,
voici une suggestion d'évolution qui éviterait d'avoir une erreur lors de la création des tables avec Mysql Workbench en utilisant le script SQL généré par Looping : pour les tables où la clé primaire est composée de plusieurs colonnes, il y en a au plus une en AUTO_INCREMENT. Il serait bien de la placer en premier dans l'expression servant à définir la clé primaire car sinon on a une erreur avec Mysql Workbench.

Exemple de script proposé par Looping :

Code sql :

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

1
2
3
4
5
6
7
8
CREATE TABLE LO_location(
   COU_ident INT UNSIGNED,
   LO_ident INT UNSIGNED AUTO_INCREMENT,  # colonne en AUTO_INCREMENT
   location VARCHAR(30) NOT NULL,
   PRIMARY KEY(COU_ident, LO_ident), # la colonne en AUTO_INCREMENT est placée en 2e dans la déclaration de PK
   UNIQUE(location),
   FOREIGN KEY(COU_ident) REFERENCES COU_country(COU_ident)
);

message d'erreur avec Mysql Workbench sur exécution de ce script :

Error Code: 1075. Incorrect table definition; there can be only one auto column and it must be defined as a key

script en mettant la colonne auto-incrémentée en premier dans la déclaration de PK :

Code sql :

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

1
2
3
4
5
6
7
8
CREATE TABLE LO_location(
   COU_ident INT UNSIGNED,
   LO_ident INT UNSIGNED AUTO_INCREMENT,  # colonne en AUTO_INCREMENT
   location VARCHAR(30) NOT NULL,
   PRIMARY KEY(LO_ident, COU_ident), # la colonne en AUTO_INCREMENT est placée en  1er dans la déclaration de PK
   UNIQUE(location),
   FOREIGN KEY(COU_ident) REFERENCES COU_country(COU_ident)
);

Pas d'erreur dans Mysql Workbench ...

[escartefigue]

bonjour Laurent

Il faut rapprocher cette remarque du MCD auquel elle se rapporte et dont je reproduis l'extrait ci-dessous

Pièce jointe 600035

Dans ce MCD, LO_location est identifié relativement (R) à COU_country, la localisation étant une entité-type faible du pays.
Dans la table issue de l'entité-type faible, la clef primaire doit être, dans cet ordre, l'identifiant de l'entité-type forte complété de l'identifiant de l'entité-type faible
Il est donc normal d'avoir dans la table LO_location, une PK composée dans cet ordre de COU_ident puis LO_ident.
Ce faisant, avec la PK déclarée comme CLUSTER (pour MYSQL, cluster index et index primaire ne font qu'un), les lignes de la table LO_location d'un même pays seront rangées de façon contiguë, ce qui est bénéfique aux performances d'accès.
Si on construisait la PK dans l'autre sens (id location puis id country) alors on dégraderait fortement les performances d'accès.

Il faut noter que l'erreur produite par MySQL n'en est pas une pour les autres SGBD, c'est l'une des bizarreries de ce SGBD.

[fsmrel]

il y en a au plus une en AUTO_INCREMENT. Il serait bien de la placer en premier dans l'expression servant à définir la clé primaire car sinon on a une erreur avec Mysql Workbench.

Comme dit Escartefigue, la clé primaire doit rester ce qu’elle est : {COU_ident, LO_ident}, elle n’a pas à être bricolée et devenir {LO_ident, COU_ident}.

MySQL (et certainement pas MySQL Workbench qui n’y est pour rien !) est très approximatif quant à la théorie relationnelle et la dénature sans état d’âme. Bref, pour conserver la clé primaire pertinente et se plier en même temps aux caprices de MySQL, il vous suffit de déclarer une clé alternative {LO_ident} :

Code SQL :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE LO_location(
   COU_ident INT UNSIGNED,
   LO_ident INT UNSIGNED AUTO_INCREMENT, 
   location VARCHAR(30) NOT NULL,
   PRIMARY KEY(COU_ident, LO_ident), 
   UNIQUE(location),
   UNIQUE (LO_ident),  
   FOREIGN KEY(COU_ident) REFERENCES COU_country(COU_ident)
);

Et MySQL prendra sa vessie pour une lanterne, et au lieu de regarder la lune regardera votre doigt qui montre celle-ci…

Pour mémoire, la norme SQL a conservé le concept de clé primaire, mais il ne s’agit ni plus ni moins que d’une clé candidate et le concept peut donc passer au rasoir d’Ockham (ce qui s’est passé avec la théorie relationnelle). Dans le code ci-dessus, {LO_ident} est clé candidate tandis que la paire {COU_ident, LO_ident} est en réalité surclé, mais cela ne pose aucun problème.

[laurentSc]

Merci pour cette astuce. Y a-t-il moyen de modifier le MCD pour que Looping génère exactement ce code ou bien faut-il modifier manuellement le script SQL qu'il génère ?

[fsmrel]

Merci pour cette astuce. Y a-t-il moyen de modifier le MCD pour que Looping génère exactement ce code ou bien faut-il modifier manuellement le script SQL qu'il génère ?

A moins d’une hypothétique astuce connue (seulement) de Paprick, à mon sens il faut modifier manuellement le script SQL.

[laurentSc]

OK