Discussion :

[Didier71]

Bonsoir...

La modélisation n'étant pas mon fort, j'ai besoin d'aide et de conseils pour arriver à mes fins plutôt que de partir sur une mauvaise piste et devoir reprendre tout après.
Donc, je voudrais créer sous Access des manuels d'instructions pour lister toutes les opérations à effectuer..
Les opérations à effectuer concernent des entreprises, et on peut avoir 2 manuels maximum par entreprise.

Je dispose déjà de la table ENTREPRISE, avec clé primaire sur CodeEnt, qui est obligatoirement unique, sans doublons.

1er point de blocage.
J'envisage une table des ACTIONS, qui pourraient s'apparenter en Word à des titres de niveau 1.
Vous voyez déjà ou je veux en venir : Il y aura bien sur des "SOUS ACTIONS", donc des titres de niveau 2, voire 3
Peux t-on gérer tout dans la même table, avec un champ indiquant le niveau ?
Mais comment être sur de rattacher les actions de niveau 2 à la bonne action de niveau 1 ?
Vaut-il mieux sans doute creer une table par Niveau ?

2ème point
Ces manuels seront différents les uns des autres, mais avec beaucoup d'actions communes tout de même. Il y aura pour certains des actions de niveau 1 qui ne figureront pas et d'autres actions de Niveau 1 qui figureront.

Est ce mieux de créer un manuel type de base contenant toutes les actions et de supprimer pour chaque manuel-entreprise ce qui est en trop ?

Si c'est oui, est il plus judicieux de creer une table MANUELBASE contenant toutes les actions, et ensuite la table MANUELENTREPRISE en supprimant ce qui est en trop ?


3ème point
Dans la tables action (et/ou sous actions) il n'y aura pas de numérotation chronologique, puisque pour certains manuels je retirerai des actions.
Quand je devrai imprimer ces manuels, comment faire pour Imprimer justement une numérotation ?
Il me semble avoir déjà vu qu'il fallait créer un champ interne numérique réel et affecter des nombres à virgule pour pouvoir insérer de nouvelles actions qui seront alors triées correctement..

Je ne vois pas comment ensuite affecter les numéros de paragraphe, si par exemple j'ai un champ interne avec une valeur à 1 et un autre à 3. La numérotation chronologique devra donc être 1, 2

4ème point
Mais quand j'en serai déjà la, je serai sauvé !!!!!!!
Il se pourrait que je doive gérer l'impression de ces manuels en anglais, même si à la base tout sera en français....

Comment gérer les traductions des actions ? dans la table même des actions ou en externe ?


J'espère que vous pourrez m'apporter quelques infos pour me permettre de débuter...
En vous remerciant.

Cordialement
Didier

[Papy Turbo]

Bonsoir,

1- il est beaucoup plus simple d'utiliser une table par niveau, avec relation entre les tables.
Pour tout mettre dans une seule et répondre à ta question, on ajoute, à côté de la clé primaire, un champ [CléParent].
Les enregistrements du 1er niveau n'ont pas de parent, ceux du niveau 2 ont la clé d'un enregistrement de niveau 1, etc.
Ce genre de table hiérarchique unique est très souple et puissante si tu as des niveaux variables. Surtout si tu ne sais pas combien de niveaux il va y avoir... Par contre, nombreux casse-têtes à prévoir (si tu as le temps, juste pour le fun, amuse toi à construire une requête qui affiche hiérarchiquement le contenu ).

2- il paraît surtout nécessaire de n'avoir qu'une seule (série de) tables d'Actions (1 table par niveau). Le + important : jamais de doublons (jamais 2 fois la même action !).
Ensuite, pour chaque entreprise, dans une table des Manuels, noter uniquement les clés :
- la clé de l'entreprise,
- chaque clé de chaque Action...

3- ... ce qui répond à ta question 3 : tu peux, dans la table des Manuels des entreprises, ajouter un simple numéro séquentiel.
À toi de voir la forme que tu veux lui donner (avec ou sans les niveaux, avec des 1.1.1 par exemple ou 1.a.1...).
Ce qui donne, pour chaque action de chaque manuel :
- la clé de l'entreprise,
- chaque clé de chaque Action,
- le numéro séquentiel, qui peut servir aussi à trier les actions de chaque manuel, pour l'impression.

4- tu décideras ça quand ça marchera en français (et, si je ne me trompe, ce sera extrêmement simple).

[marot_r]

Si tu travailles avec une bibliothèque fixe d'actions et que ces actions se retrouvent dans plusieurs manuels voilà ce que je ferais.

Table Paragraphe

ClefParagraphe (numauto, clefprimaire)
ClefParagrapheParent (entier long, relie le paragraphe courant au paragraphe qui le contient, Null si pas de contenant)
Pararagraphe (mémo)
OrdreParagraphe (Reel double)

Table Manuel

ClefManuel (numauto)

Table AssManuelParagraphe

ClefAssMaunuelParagraphe (numauto, clefprimaire)
ClefManuel (entier long, index unique en combinaison avec ClefParagraphe)
ClefParagraphe (entier long, index unique en combinaison avec ClefManuel)
InclureEnfant (boolean, vrai si il faut inclure tous les enfants du paragraphe)
OrdreParagrapheManuel (Reel double)

L'index unique évite qu'on mette 2 fois le même paragraphe dans le manuel.

Table AssManuelEntreprise

ClefAssManuelEntreprise (numauto, clef primaire)
ClefEntreprise (entier long, index unique en combinaison avec ClefAssManuelParagraphe)
ClefAssManuelParagraphe (entier long, index unique en combinaison avec ClefEntreprise)
OrdreParagrapheEntreprise (Reel double)

L'index unique évite qu'on mette 2 fois le même paragraphe dans le manuel de cette entreprise

Selon le nombre d'ajouts ou de retraits au modèle, il peut être pertinant de recopier le modèle dans le manuel de l'entreprise ou de partir à rien et d'ajouter les morceaux qui t'intressent.

Après pour la numérotation d'impression, tu la fais à l'impression pas avant.

Les champs Ordre... te permettent de décider dans quel ordre tes paragraphes ou tes ensembles de paragraphes vont s'imprimer.

Pour l'impression il faudra sans doute remplir une table temporaire et recopier tous les paragraphes dedans avec un parcourt/ajout des enfants de chaque paragraphe. Y calculer les numérotations puis s'en servir pour l'impression.

La table d'impression ressemblerai à

ClefImpression (numauto, clefprimaire)
ClefEntreprise (pas indispensable mais utile pour une personnalisation)
ClefManuel (EntierLong, pas indispensable mais utiles pour une personnalisation)
ClefParagraphe
OrdreParagrapheEntreprise
OrdreParagrapheManuel
OrdreParagraphe

En triant sur OrdreParagrapheEntreprise, OrdreParagrapheManuel, OrdreParagraphe tu devrais avoir tous les morceaux dans le bon ordre.

Il faudrait peut-être aussi avoir une notion de Type de paragraphe pour distinguer les titres du texte.

A+

[marot_r]

Pour la langue la méthode la plus simple consiste à avoir 2 champs, un pour le français et un pour l'anglais.

La méthode la plus 'propre', celle que je recommande, consiste à avoir un code de langue sur le paragraphe et d'avoir un enregistrement paragraphe par langue. Cette solution permet ensuite de sortir facilement un manuel dans la langue que tu veux sans aucune modification à la chaîne de traitement.

Évidement la saisie de la traduction est un peu moins évidente dans la seconde solution car il est plus difficile d'avoir le texte orginal et sa traduction côte à côte sur une même ligne.

Un moyen de résoudre cela serait une table temporaire qui comporte les champs suivant :

CelfParagraphe
TexteOriginal
CodeLangue
TexteTraduit
CodeLangue

d'y copier les paragraphes en Français, de saisir la traduction et d'injecter la traduction dans la table des pargraphes avec le code langue voulu. On a ainsi le meilleur des deux mondes :-)

A+

[JLCantara]

Bonjour René,

Évidement la saisie de la traduction est un peu moins évidente dans la seconde solution car il est plus difficile d'avoir le texte orginal et sa traduction côte à côte sur une même ligne.

Bin non, rien de compliqué; soit le modèle simple suivant

Paragraphes (Table)
Paragraphe, auto, clè primaire
ParaFr, memo ou varchar(xxx)
ParaAng, memo ou varchar(xxx)

On construit 2 requètes: une qui retourne Paragraphe et ParaFr (vwParaFr) et une autre qui retourne Paragraphe et ParaAng (vwParaAng).

On construit 2 formulaire minimaux frmParaFr et frmParaAng basés sur les requètes idoines.

On construit le formulaire de traduction de la façon suivante:
1- dans le 'header', mettre un champ texte (txtParagraphe) pour recevoir l'ID du paragraphe (Paragraphe);
2- ajouter 2 sous-formulaires, frmParaFr et frmParaAng tout en s'assurant qu'ils sont liés à txtParagraphe.
3- Noton qu'il faut gérer la simultanéité: pas sur que Access soit capable de gérer une modif. simultané.

Ainsi, lorsqu'on entre un no. de paragraphe, on obtient automatiquement la version française (disons à gauche) et la version anglaise, en entrée ou révision, à droite.

Viva Calvillo,
JLCantara.

[marot_r]

Je suis d'accord avec toi JLCantara, ce que tu décris c'est ma première solution.

Ce que tu as mis en exergue concerne ma 2ième solution où le texte original et sa traduction sont dans 2 enregistrements séparés.

La 1ère solution devient très pénible dés que tu veux ajouter une langue (ex : une version en allemand ou en espagnol). Il faut créer un nouveau champ, une nouvelle série de requêtes et un nouvel écran ... bref c'est quand même beaucoup de travail juste pour une langue et il faut recommencer à la suivante.

La seconde solution avec 1 langue par enregistrement permet de ne pas avoir à changer quoi que ce soit au traitement, écran et autres. Il suffit de seulement ajouter un code de langue et ses textes. Mais la saisie des traductions est un peu moins évidente.

A+

[Richard_35]

Bonjour Didier71, Papy Turbo, Marot_r et JLCantara,

Je me permets de m'immiscer...

Il vaudrait mieux que la numérotation des paragraphes/sous-paragraphes soit dynamique en fonction de l'arborescence que Access trouve au moment d'éditer le manuel. De ce fait, les insertions d'actions s'effectueront facilement par affectation d'une action mère.

Reprenons les règles de gestion :

1 entreprise peut avoir 2 manuels maximum ;
1 même manuel peut-il concerner plusieurs entreprises ? (supposons que oui) ;

1 manuel comporte plusieurs actions ;
1 même action peut concerner plusieurs manuels ;

1 manuel est rédigé en 1 ou plusieurs langues ;
1 langue peut être le langage de 1 ou plusieurs manuels ;

1 action peut avoir 1 et 1 seule action mère ;
1 action mère peut posséder plusieurs actions filles.

1 action peut être rédigée en 1 ou plusieurs langues ;
1 langue peut être le langage de 1 ou plusieurs actions.

Didier71, en premier lieu, es-tu d'accord avec ces règles de gestion, notamment celle soulignée qui est d'une très grande importance ?

[Didier71]

Bonjour à tous !

Tout d'abord merci pour l'intérêt que vous portez à mes interrogations..
Avec toutes les infos que vous m'avez données, j'ai déjà de quoi bosser ce week-end !

Pour répondre à la question de Richard,
Je suis d'accord avec les règles de gestion écrites,
en particulier 1 action peut avoir une seule action mère

Merci encore pour vos conseils très éclairés.
Je ne ferme pas la discussion, car j'aurai sans doute d'autres demandes....

Bon week end !

Didier71

[JLCantara]

Bonjour à tous les répondants,

Question à Didier:

Prévois-tu stocker tes données dans SQL Server Express? ton application en serait grandement simplifiée car celà sent la stored procedure à plein nez.

------------------------------------------------------------------------

Question à René:

Tu vois l'arbre mais pas la forêt! Dac, j'ai mal vu le passage d'un cas à l'autre mais l'exemple que j'ai donné ne reçoit aucun commentaire, pourquoi?
Effectivement, une fiche d'action par langue est la meilleure solution; mais celà ajoute une complexité non négligeable i.e. l'action doit être dissociée de son texte ce qui,au fond, est une bonne chose puisqu'un intitulé pourrait être associé à l'action (utile pour les ComboBox.
Ajoutant un code de langue, l'exemple que j'ai donné s'applique sans difficulté. On pourrait même imaginer, pour la traduction, un formulaire à onglet, un onglet par langue. As-tu déjà eu l'occasion d'utiliser ce genre de formulaire?

-----------------------------------------------------------------------

Question aux responsables de Développez:

Ce projet touche un domaine pas si simple à traiter; il y aura de nombreux pièges à éviter; alors pourquoi ne pas en faire une étude de cas très sophistiquée?

-----------------------------------------------------------------------

Bonne fin de semaine à tous,
JLCantara.

[Didier71]

Bonjour A tous,

Pour répondre à la question de JLCantara, non....

J'ai donc commencé à construire les tables en tenant compte de la structure indiquées par René et les règles de gestion décrites par Richard..

Il y a des choses qui me "chiffonnent" et je vous soumettrai peut être un schéma des relations pour que vous puissiez me corriger..

Bon week end.

Didier

[Richard_35]

Bonjour à tous,

Les règles de gestion que tu as validées donnent le schéma suivant :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
Entreprise -1---8- Entreprise_Manuel -8---1- Manuel -1---8- Manuel_Action -8---1- Action -1---8-+
                                                |                                   | |         |
                                                1                                   1 +---------+
                                                |                                   |
                                                8                                   8
                                                |                                   |
                                           Manuel_Langue                       Action_Langue
                                                |                                   |
                                                8                                   8
                                                |                                   |
                                                1                                   1
                                                |                                   |
                                                +--------------Langue---------------+

Je te laisse déduire la structure des tables qui est relativement évidente.

Remarques :

• remplacer les 8 par le signe infini ;
• la relation réflexive sur Action nécessite l'ajout la même table Action liée avec elle-même via IdActionMere ;
• il est envisageable de traduire des actions dans une certaine langue non encore liée au manuel correspondant : dès que cette liaison sera effective, l'action traduite sera intégrée automatiquement. C'est pourquoi, il n'est peut-être pas nécessaire de tester si la langue est liée au manuel pour savoir si l'action doit l'être (à voir).

Enfin, le noeud du problème : la numérotation :
Elle s'effectue, dynamiquement, en "balayant" Action et en déduisant les niveaux (1, 1.1, 1.2, 1.2.1, etc...).
Il suffira de "jouer" avec l'action "mère" pour insérer/supprimer des paragraphes.
Je ne sais pas s'il est possible, sous Access, de créer des fonctions récursives mais, si c'est le cas, ce sera la bonne solution.
Le code VBA (que je ne connais pas) est assez délicat à concevoir, mais cela vaut le coup de passer du temps dessus : une fois mis au point, plus de problème.

[Papy Turbo]

Bonjour, tout le monde.

On est bien partis, là

Belles solutions, pas de doute, mais je maintiens quand même que la hiérarchie des actions utilisant une table par niveau, si elle est moins 'élégante', est beaucoup plus simple à mettre en œuvre, notamment au niveau de la saisie dans x requêtes > x sous-sous-...formulaires imbriqués.
Le choix dépend :
1- est-ce que Didier se sent débutant ou expert en matière de tables, les relations, et leur utilisation dans les requêtes et (sous-)formulaires hiérarchisés ?
2- niveau métier, seul Didier, ou plutôt les utilisateurs de ces manuels peuvent répondre : Y a t-il un nombre maxi restreint de niveaux (ex. 3 ou 5 niveaux maximum) ?
Si Oui, 3 ou 5 tables de niveau 1 à x, avec une relation d'intégrité entre niveaux permet déjà
- d'afficher tout en imbriquant les 'subdatasheets' les unes dans les autres,
- idem dans un formulaire, avec sous-formulaires.
Enfin, la numérotation (par exemple 1.2.1) est ultra-simple, puisqu'on a juste les clés (n°s d'ordre) de chaque parent, dans le cadre de chaque manuel d'entreprise : pas de balayage ni de récursif (Oui, on peut faire du récursif dans les fonctions vba, même dans une requête. Voir Formule1)

Bien sûr, je préfèrerais la solution table unique détaillée par Richard, pour un système universel, sans limite du nombre de niveaux. Mais là, je suppose que Didier connaît suffisamment le contenu de ses manuels, et qu'il peut simplifier.

Sinon, question 4, je vois que JLCantara et René sont bien partis sur la traduction.
Là aussi, si on vise au + simple, je vote pour la 1ère solution, reprise par JL, avec un champ Para ou ActionFR pour le français, ...EN pour l'anglais, puis (si nécessaire ?) ...ES pour l'español, etc.
À voir :
- si c'est difficile de rajouter un seul champ (toujours le même) dans chaque table d'actions, ou si ça prend juste 1/2h un vendredi soir ?
- si même Didier envisage d'avoir + de 2 langues ?
Si oui, pour un système de traduction côte à côte (indispensable), je préconise certainement le formulaire unique ayant les 2 champs mémo,
- soit direct dans 2 contrôles, dont on peut facilement changer la source à l'ouverture (en vue Design) pour que l'1 affiche le français, l'autre l'anglais ou l'espagnol...
- soit, + souple, on laisse l'utilisateur changer la langue de chacun des 2 contrôles mémos :
++ 2 listes déroulantes en tête du formulaire conteneur, affichant chacune le choix entre toutes les langues disponibles,
++ les champs communs (la clé) de l'action (champ père) dans le formulaire principal, (peut être invisible si rien d'autre)
++ 2 sous-formulaires contiennent chacun la clé (champ fils, invisible) + un seul champ mémo dont la langue est variable,
- Source du sous-formulaire =

Code :

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

SELECT CleAction, MemoActionFR FROM TableACTION

où "FR" est le code obtenu de la liste déroulante correspondante, modifiable à la volée dans ListeLangue_AfterUpdate().

On peut assez facilement, je pense, imbriquer cela sur plusieurs niveaux pour respecter la hiérarchie des Actions, soit dans la liste exhaustive complète, soit dans la liste (le Manuel) pour chaque entreprise.

Tu t'y retrouves, Didier ?

[Didier71]

Bonsoir !

Ouh la la ! que d'informations.... Pas sur que je m'y retrouve.

Tout d'abord, voici en pièces jointes le schéma des relations que j'ai fait d'après les indications de Richard...

J'ai déjà deux questions peut être naives, mais bon... Dans la table Manuel, j'ai ajouté un champ TitreManuel : Ma question est :" ou mets-je la traduction du titre en anglais ? "Dans la table Manuel ou dans la table Manuel_Langue ?

Meme question en fait pour les "actions".... table ACTION ou table ACTION_LANGUE..

Maintenant je vais répondre aux question de Papy Turbo.

- Je ne suis pas du tout expert en relation-tables-requetes.. etc.. Débutant me semble approprié pour ce domaine.
- De même que je ne me sens pas à l'aise avec la récursivité !!!
La solution d'une table par niveau me parait plus alléchante, enfin pour moi. De plus, il n'y aura jamais plus de 5 niveaux..

- Ces manuels n'existent pas encore vraiment.. Dans mon service, chacun a des bouts de Word, des copies d'écran, des mails etc.. Ca ne me plait pas du tout et j'aimerai bien unifier tout ça. DOnc, étant à l'origine de la chose, je ne vais pas faire une usine à gaz , mais bien évidemment simplifier.

- En ce qui concerne les langues, cela m'étonnerait que nous en ayons plus de 2 ! Nous travaillons en français, mais pour des entreprises étrangères. Si on doit partager quelque chose, ce sera en anglais de toute façon, et en édition, c'est pour ça que je le prévois..La base elle même ne sera pas partagée.

-Comme c'est moi qui ferais toutes les traductions, le système de formulaire,
avec les champs côte à côte est séduisant, mais je n'en suis pas encore là.


Du coup, je vais peut être abandonner la récursivité, et faire une table par niveau, en limitant le niveau...
A l'extrême limite je peux même faire un seul niveau... Ce sera donc une banale suite d'actions chronologique....

Avant de passer au desgin des formulaires, il faut donc que choisisse une stratégie....


Je vais sans doute revenir vers vous avec un nouveau schéma sans récursivité...

Merci encore.

Cordialement
Didier

[Papy Turbo]

Bonsoir,

Ma question est :" ou mets-je la traduction du titre en anglais ? "Dans la table Manuel ou dans la table Manuel_Langue ?

Meme question en fait pour les "actions".... table ACTION ou table ACTION_LANGUE..

Tu réponds toi même à la question :

- En ce qui concerne les langues, cela m'étonnerait que nous en ayons plus de 2 !

Pour moi, c'est simple :
- Tu choisis d'abord, soit une seule table avec clé parent (comme ton modèle), soit (pour moi le + simple) 5 tables l'une dans l'autre,
- dans chaque table, un Titre_FR + un Titre_EN et un double mémo : Action_FR + Action_EN.
Aucune table spécifique aux langues : restons simple, d'autant plus que passer à un système multi-langue + tard, si nécessaire, sera aussi facile.

Enfin, je termine par ton commencement :

Tout d'abord, voici en pièces jointes le schéma des relations que j'ai fait d'après les indications de Richard...

As tu, là aussi, besoin de la table Entreprises_Manuel, par exemple ?
>> Une entreprise peut avoir plusieurs manuels - OK
>> Un même manuel peut servir (sans aucune modif) à plusieurs entreprises ??? ou tu prévois plutôt (à l'usage) que chaque entreprise va; ici ou là, modifier quelque chose de spécifique ?
Autrement dit, chaque manuel ne sera utilisé que par une entreprise ? (quitte à prévoir une fonction qui copie entièrement un manuel existant d'un entreprise pour une autre : ce ne sont que des clés.)
Dans ce cas, pas besoin de [Entreprises_Manuel].
Les 5 table(s) de [Manuel] ont juste (voir + haut) 3 champs :
- une clé d'entreprise,
- un n° d'ordre, pour le tri final des actions dans le manuel (affichage, impression),
- la clé de l'action à inclure.

Il reste :
- 5 tables Actions1 à 5, incluant anglais + français,
- 1 table Entreprises,
- 5 tables Manuels1 à 5.

[Richard_35]

Bonsoir à tous,

Le schéma est OK mais, attention, si, pour les tables associatives (n,n), tu crées une clé primaire avec un seul champ, il faut impérativement créer un index unique avec les deux champs constituant la "vraie clé primaire".

J'ai déjà deux questions peut être naives, mais bon... Dans la table Manuel, j'ai ajouté un champ TitreManuel : Ma question est :" ou mets-je la traduction du titre en anglais ? "Dans la table Manuel ou dans la table Manuel_Langue ?

==> le français est une langue à créer dans la table langue. En conséquence, le champ "TitreManuel" doit être dans la table MANUEL_LANGUE dans la langue correspondante à CleLangue de cette même table. Même combat pour les actions.

La solution faisant intervenir la récursivité est, c'est vrai, plus complexe à mettre en place mais elle est facilement évolutive (une fois mise en place... ).

Au passage, Papy Turbo, René et JLCantara.

[Papy Turbo]

Bonjour, Richard, bonne semaine à tous,

Je me sens un peu lourd d'insister comme ça, mais c'est le débat
Richard, nous ne sommes pas d'accord sur l'emplacement des champs français et anglais.
Je suis très partisan d'un système multi-langues, réutilisable dans toutes les applications... mais je pense que ça demande beaucoup de travail supplémentaire, pas toujours simple, et je ne l'utiliserai moi-même que s'il est encapsulé dans une bibliothèque réutilisable en 3 clics, ce qui n'est pas le cas (et encore + de boulot).

Encore une fois,
- Didier se déclare lui-même débutant, d'où besoin du plus simple pour commencer et réussir "quelque chose qui marche bien tout de suite" (1 des principes de base des méthodes agiles);
- il n'envisage aucune 3ème langue, au moins pas le temps de terminer cette phase (prochaine phase, prochain budget, on verra...).
Pourquoi créer une ou des tables de langue, avec leurs complexités structure > requêtes > formulaires > états..., là où il a besoin, pour la phase actuelle, de mettre côte à côte 2 titres (FR+EN) et 2 mémos ?

[Richard_35]

Bonjour Etienne et à tous,

Je me sens un peu lourd d'insister comme ça, mais c'est le débat

==> non, non, pas de problème : c'est le principe d'argumentation/contre-argumentation. Quand celui-ci est productif, alors il est enrichissant.

Pourquoi créer une ou des tables de langue, avec leurs complexités structure > requêtes > formulaires > états..., là où il a besoin, pour la phase actuelle, de mettre côte à côte 2 titres (FR+EN) et 2 mémos ?

==> C'est vrai que la solution "un champ par langue" fonctionne. Néanmoins, attention aux requêtes qui devront tester le nom du champ (xxx_FR ou xxx_EN) en clair.

Et que dire si Didier71 doit, un jour, ajouter la langue allemande... OK, ce n'est pas à l'ordre du jour, mais nous avons tous connu des sujets qui ne sont pas à l'ordre du jour, qui deviennent urgents, à terme, et au sujet duquel les utilisateurs penseront qu'il est évident qu'il fallait le prévoir...

En final, je ne pense pas que la solution "liens dynamiques entre tables" soit plus compliquée que la solution "un champ par langue".

[Didier71]

Bonsoir à tous...


Je vois que mon sujet suscite toujours autant de débats !
C'est très intéressant tout ça...
Donc j'ai refait un schéma d'après les indications de PapyTurbo, (voir capture ci-jointe).
Volontairement j'ai limité à 2 niveaux, et paradoxalement, même si c'est plus simple, je n'ai pas tout compris, même pas sur que les relations soient bonnes.
Pourquoi 5 tables de Manuel ? (une par niveau je suppose..)

Même s'il faut mettre en place la récursivité (aie !) je comprenais mieux le schéma précédent !

Du coup, je ne sais que faire.....

J'ai déjà construit une petite base avec des données bidons, basée sur le modèle de Richard.. Si je la joins dans un autre mail, vous pourrez me dire si je peux continuer comme ça ?

Merci d'avance

Didier71

[Papy Turbo]

Bonsoir, Richard, Didier

Oui, j'ai aussi été un peu confus avec ton schéma, et je n'ai pas pu résister au dessin rapide (ça va assez vite de recopier les tables, puis de rajouter une clé), pour y voir + clair. Je n'ai utilisé que 3 niveaux, par flemme.

Donc, Oui : 5 tables pour 5 niveaux, à la fois pour les Actions, et leur insertion dans les manuels des entreprises.

Par contre, je vois que tu as ajouté des champs concernant l'ensemble du manuel (Titre, date création...). Tu penses trop ! Non, je rigole, j'ai ajouté la table 'Manuels'.
Du coup :
- les tables Manuels1 à 5 deviennent Manuels_Actions1 à 5, (liste des actions de chaque niveau qui composent le manuel)
- j'ai utilisé 2 schémas différents :
++ pour les Actions, simple répétition dans la table enfant de la seule clé parent,
++ pour les MANUELS_ACTIONS, répétition de toutes clés du niveau 1 au niveau x.
Chaque méthode a ses avantages (+ léger ou + explicite...) : à toi de choisir.

Sinon, bien d'accord, Richard : il y aura un peu plus de boulot pour passer à un système multi-langues + tard. À Didier de choisir ?

P.S. grosse bourde dans la relation Manuels -> Manuels_Actions1.
J'ai laissé l'index unique sur la copie de CleManuel, mais je suppose que tu avais déjà corrigé pour remettre une relation de 1 manuel -> tout plein d'actions1...

[Didier71]

Bonsoir...

Bon, finalement j'ai choisi la solution de Papy Turbo...
Le schéma est clair, j'ai rectifié la jointure aussi.

Mais j'ai un problème d'index introuvable dans la table principale
quand je veux relier le champ CleManuel de la table MANUELS_ACTIONS1 au champ CleManuel de la table MANUELS_ACTIONS2....

Est ce parce ce que j'ai déjà des données bidons dans ma table ?
ou que j'ai mal crée les clés primaires ????

Je joins la base pour correction... si vous pouviez regarder, cela m'arrangerait..
Ensuite, je vais "attaquer" tout ce qui est formulaires etc...

Merci pour votre aide..
Bonne soirée
Didier71