Discussion :

[CinePhil]

Bonjour,

Est-il possible, dans Looping, de préciser le nom du schéma (ou de la BDD MySQL/MariaDb, même si ce n'est pas la même chose) auquel appartient l'entité-type ?

L'idée est de pouvoir représenter associations entre un schéma principal et un schéma de référentiel (pays, villes, types, civilités...) potentiellement utilisable par plusieurs schémas (ou BDD MySQL).

J'ai essayé d'écrire dans le nom logique nom_schema.nom_future_table mais Looping remplace le point par un _.

[Paprick]

Bonsoir Philippe,

Looping ne gère pas aujourd'hui les MCD regroupant plusieurs schémas.
Mais, comme tu le sais, je suis ouvert à toute proposition d'évolution du logiciel.
Peux-tu me donner un exemple complet de la façon dont tu verrais les choses, l'idée étant ensuite de trouver une approche générique d'une gestion multi-schéma.

[CinePhil]

Voilà en pièce jointe un exemple de ce que je suis en train de faire avec MySQL Workbench. Une BDD qui servira à la partie publique d'une application web et une BDD référentiel qui servira aussi à la BDD de la partie privée de l'application.


Comme c'est sous MySQL, il y a des clés étrangères entre deux BDD mais sous un autre SGBD, ça pourrait être au sein d'une BDD entre plusieurs schémas.

[Paprick]

Bonjour,
Je commence à voir comment ça pourrait fonctionner assez simplement avec Looping.
Pourrais-tu me donner, avec un exemple simple, le code généré pour la création de la table locale lorsqu'elle fait référence à une table provenant d'une autre BD ?
Et est-ce que ce sera standard ou spécifique à MySQL ?
Merci !

[CinePhil]

Bonjour
Dans MySQL, il est possible de faire ce genre de requête :

Code SQL :

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

1
2
3
SELECT bdd1..table1.colonne1, bdd2.table2.colonne2
FROM bdd1.table1
INNER JOIN bdd2.table2 ON bdd2.table2.colonne1 = bdd1.table1.colonne1

Dans les autres SGBD, c'est possible entre schémas au sein d'une BDD mais en principe les BDD sont étanches, sauf à l'aide de mécanismes particuliers. On peut donc faire, chez Oracle ou PostgreSQL ce genre de requête :

Code SQL :

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

1
2
3
SELECT schema1..table1.colonne1, schema2.table2.colonne2
FROM schema1.table1
INNER JOIN schema2.table2 ON schema2.table2.colonne1 = schema1.table1.colonne1

Et dans MySQL, on peut créer une clé étrangère référençant une table d'une autre BDD :

Code SQL :

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

1
2
ALTER TABLE bdd1..table1 
ADD CONSTRAINT fk_colonne1 FOREIGN KEY (colonne1) REFERENCES bdd2.table2 (colonne1) ON DELETE CASCADE ON UPDATE CASCADE;

Sous réserve de vérification, il me semble que dans les autres SGBD, on peut faire de même entre schémas d'une même BDD, mais cette fois ci pas entre BDDs qui restent étanches sur ce plan car les journaux (undo, redo-logs et archive_logs) des BDD sont propres à chaque BDD.

Exemple de table qui fonctionne sous MySQL :

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
17
18
19
20
21
22
23
24
25
26
27
28
-- Structure de la table te_telephone_tel
CREATE OR REPLACE TABLE te_telephone_tel (
  tel_id int(11) NOT NULL COMMENT 'Identifiant du numéro de téléphone',
  tel_id_personne int(11) NOT NULL COMMENT 'Identifiant de la personne à qui appartient le numéro de téléphone',
  tel_id_type_telephone tinyint NOT NULL COMMENT 'Identifiant du type de numéro de téléphone',
  tel_numero varchar(20) NOT NULL COMMENT 'Numéro de téléphone	'
) 
ENGINE=InnoDB 
DEFAULT CHARSET=utf8mb4 
COMMENT='Numéros de téléphone';
 
-- Index pour la table te_telephone_tel
ALTER TABLE te_telephone_tel
  ADD PRIMARY KEY (tel_id),
  ADD UNIQUE KEY xu_tel_numero (tel_id_personne,tel_id_type_telephone,tel_numero) USING BTREE,
  ADD KEY x_tel_id_type_telephone (tel_id_type_telephone);
 
-- AUTO_INCREMENT pour la table te_telephone_tel
ALTER TABLE te_telephone_tel
  MODIFY tel_id int(11) NOT NULL AUTO_INCREMENT COMMENT 'Identifiant du numéro de téléphone';
 
-- Contraintes pour la table te_telephone_tel
--
ALTER TABLE te_telephone_tel
  ADD CONSTRAINT fk_tel_id_personne FOREIGN KEY (tel_id_personne) REFERENCES te_personne_prs (prs_id) ON DELETE CASCADE ON UPDATE CASCADE,
 
-- Ci-dessous, clé étrangère réferençant une table de la BDD referentiel :
  ADD CONSTRAINT fk_tel_id_type_telephone FOREIGN KEY (tel_id_type_telephone) REFERENCES referentiel.tr_type_telephone_tyt (tyt_id) ON DELETE NO ACTION ON UPDATE CASCADE;

[Paprick]

Bonsoir,
Est-ce que la solution simpliste suivante suffirait :
Dans la fenêtre des classes d'entités, rajout d'une case à cocher : "Classe appartenant à une BD externe", et si la case est cochée :
- Mettre le contour de la classe en pointillés (sachant qu'il y aura aussi la possibilité de changer la couleur de fond de n'importe quel objet à partir de la version 2.6).
- Pas de présence dans le MLD et pas de CREATE dans le script SQL pour la table correspondante.
- Autoriser tous types de caractères (les points entre autres) dans le nom logique.
Ainsi, en déclarant "externes" les tables de la BD référentiel, et en indiquant les noms logiques complets des tables incluant, par exemple, en préfixe le nom de la BD externe, le script de création du schéma relationnel serait opérationnel sans rien changer à Looping....
On pourrait alors définir, dans un MCD à part, la BD référentiel avec les options ci-dessus, puis faire un copier-coller dans tout autre MCD en rajoutant ensuite les associations qui vont bien...
Ce serait un peu passe partout (BD externes, inter-schémas, ...) , assez simple à réaliser... mais est-ce suffisant ?

[CinePhil]

Oui, je pense que ça peut le faire. Le but n'est effectivement pas de générer le code de la BDD ou schéma externe au modèle mais bien de prendre en compte les associations qui existe vers ce schéma ou BDD externe à celui modélisé.

[Paprick]

Oui, je pense que ça peut le faire. Le but n'est effectivement pas de générer le code de la BDD ou schéma externe au modèle mais bien de prendre en compte les associations qui existe vers ce schéma ou BDD externe à celui modélisé.

Ok, je pars sur cette idée (peut-être dès la version 2.6) : si des précisions doivent être apportées, merci de me les indiquer dès que possible.

[Paprick]

Bonjour,
Afin de ne pas alourdir l'interface, je préfère que les BDD externes soient spécifiées directement et seulement dans le nom logique des classes concernées.
Pour cela, on peut soit préfixer le nom complet de la table externe avec un caractère particulier : @ $ \ % ..., soit l'encadrer : () [] {} ...
Quelle notation serait la plus adaptée à la situation (et pourrait éventuellement se rapprocher d'un standard utilisé dans une situation analogue) ?

[CinePhil]

Si c'est inévitable, je préférerais l'encadrement.

[Paprick]

Finalement, je pense avoir trouvé le compromis : je laisse la case à cocher, mais elle ne s'affichera (décochée par défaut) que si le nom logique est saisi.

[CinePhil]

Et donc, dans le nom logique, il suffira de saisir un nom du genre schema_externe.nom_table pour que la case à cocher apparaisse et que cette table ne soit pas prise en compte dans la génération SQL ?

[Paprick]

Et donc, dans le nom logique, il suffira de saisir un nom du genre schema_externe.nom_table pour que la case à cocher apparaisse et que cette table ne soit pas prise en compte dans la génération SQL ?

En fait, dès que le nom logique commencera à être saisi, la case à cocher apparaîtra et pourra (ou pas) être cochée.
Si la case est cochée, tous les caractères seront alors autorisés : le point, mais aussi tout autre caractère qui pourrait être nécessaire à certains SGBD pour désigner une table externe.