Liaisons multi tables : Lookup ou références

Demandes d'aide
1

Bonjour,

Je travaille au service Agriculture de la DDT de la Drôme et nous souhaitons étudier la migration de certains de nos tableaux de suivis partagés dans Grist.

Pour test, j’ai déjà migré dans Grist l’instruction de l’éligibilité des exploitants aux aides de la Pac :

Plus habitué aux SGBD type Access ou Posgresql, j’ai utilisé Grist sans utiliser le principe des références (simples ou multiples), mais plutôt avec des pseudo-liaisons (LookupOne et LookupRecords sur un identifiant commun entre les tables) pour rapatrier des données de diverses tables dans une table principale d’instruction.
Nous faisions un peu la même chose (en moins puissant) dans des tableurs avec RechercheV.

L’idée (simplifiée) :

  • une table principale avec identifiant (n° Pacage) + champs d’instruction (saisis lors de l’instruction) + champs rapatriés de plusieurs autres tables
  • autres tables (identifiant : n° Pacage), plusieurs lignes par Pacage possibles
    Ces « autres tables » sont des extractions csv du logiciel national de la PAC. Elles devront être mises à jour régulièrement dans Grist
    Pour l’instant pour une mise à jour d’une extraction csv, j’efface toutes les données de la table et les remplace par les nouvelles données.
    (je verrai plus tard si c’est possible d’automatiser)

Dans mon modèle déjà testé, cela fonctionne parfaitement bien avec les Lookup :

  • du plus simple : ex : Exploitants_sa.lookupOne(pacage=$pacage).forme_juridique_sa
  • ou plus élaboré (lookupRecords) avec rapatriement de données de plusieurs champs de plusieurs lignes pour un même Pacage.

D’où mes questions, car j’ai sûrement loupé quelque-chose dans le concept des références de Grist :

  • Comment utiliser un champ de type Référence si on veut pouvoir faire des « liens » avec plusieurs autres tables. J’ai pensé créer plusieurs champs Référence (un pour chaque liaison avec la table concernée) mais cela me semble lourd car il faut que je recopie le numéro Pacage dans chaque champ pour autant de liaisons nécessaires
    Est-ce la seule solution ?
  • de plus, en cas de mise à jour des « autres tables », si j’efface/remplace les lignes ou que j’écrase: ça bugue car Grist perd la liaison avec l’Id de ligne.
  • dans notre cas d’utilisation de Grist, devons nous rester avec la « méthode » Lookup ?

En vous remerciant pour votre expertise.
Bien cordialement

Emmanuel Guiset

2

Bonjour Emmanuel,

Si je comprends bien ton souci, il y a deux choses :

  • Comment remplacer les références en Lookup par du natif Grist ?
  • Comment mettre à jour facilement le référentiel ?

Pour remplacer les références sans devoir tout remettre à la main, si tu as déjà ton référentiel en place (Pacage), tu peux créer une nouvelle colonne ‹ Référence › ou ‹ Référence multiple › si la relation est de type 0-n.

Pour ensuite peupler cette colonne, tu peux effectuer un import qui va venir la mettre à jour.

Menu ‹ Nouveau › → ‹ Import depuis un fichier ›. Dans l’interface d’import, tu peux choisir de mettre à jour les enregistrements existants en sélectionnant la colonne d’appairage.

image
image1461×727 26.9 KB

Ensuite, tu mappes les bonnes colonnes de ton fichier CSV / Excel. Normalement, ton fichier devrait avoir 2 colonnes, avec le même ID dans chaque colonne.

(Attention, le n° de Pacage doit déjà exister dans la table de référence, sinon la cellule apparaîtra en rouge suite à l’import.)

Une fois l’import effectué, tu devrais maintenant avoir ta colonne ‹ Référence › native Grist correctement peuplée.

Pour le deuxième point, afin de mettre à jour le référentiel, je pense qu’un import en mettant à jour les enregistrements déjà existants devrait convenir. Lorsque tu mettras à jour ce référentiel, cela mettra automatiquement à jour la référence dans les autres tables.

Exemple : tu as une référence au n° de Pacage 123456, tu affiches le nom du Pacage dans une autre table. Tu mets à jour le nom du Pacage dans le référentiel, et cela se mettra à jour dans les tables concernées.

Enfin, concernant ton point :

Comment utiliser un champ de type Référence si on veut pouvoir faire des « liens » avec plusieurs autres tables. J’ai pensé créer plusieurs champs Référence (un pour chaque liaison avec la table concernée) mais cela me semble lourd car il faut que je recopie le numéro Pacage dans chaque champ pour autant de liaisons nécessaires

Si tu veux afficher plusieurs informations en relation avec une ou plusieurs tables, je pense que la bonne méthode est d’ajouter des vues liées et non d’ajouter des colonnes de références. A partir du moment où tes relations entre tes tables sont fait, tu peux ajouter une vue à la page. Par exemple, sur ta table principale des pacage, tu peux ajouter des vues des autres tables. Au clic sur une ligne de la table principale, cela t’affichera que les lignes liées des autres tables (Même fonction qu’un outil de BI classique).

J’espère avoir répondu à tes interrogations.

Belle journée,
Victor

1 « J'aime »
3

Merci beaucoup Victor pour tes explications.
Mon modèle avec Lookup fonctionne tès bien mais j’ai l’impression de ne pas utiliser la puissance de Grist et j’aimerais comprendre :

Prenons mon modèle (simplifié pour l’exemple) :

table « exploitants » (issue d’une extraction csv) (1 seule ligne par pacage) : champs pacage, nom, date de naissance, forme juridique
table « dossiers » (issue d’une extraction csv) (1 seule ligne par pacage) : champs pacage, surface_exploitée
table « periodes_eligibilité » (issue d’une extraction csv) (plusieurs lignes par pacage) : champs pacage, date_debut, date_fin, eligibilité (oui/non)

=> j’instruit mes dossiers dans une table « instruction »
champs :
pacage (champ saisi)
nom (issu de la table « exploitants »)
date de naissance (issu de la table « exploitants »)
forme juridique (issu de la table « exploitants »)
surface_exploitée (issu de la table « dossiers »)
date_début (issu de la table « periodes_eligibilité » : plusieurs occurences)
date_fin (issu de la table « periodes_eligibilité » : plusieurs occurences)
éligibilité (issu de la table « periodes_eligibilité » : plusieurs occurences)
commentaires (champ saisi)

J’essaie cette solution :
Dans la table "instruction, je défini le champ pacage comme Référence sur la table « exploitants »
Dans la table « dossiers », je défini le champ pacage comme Référence sur la table « exploitants »
Dans la table « periodes_eligibilité », je défini le champ pacage comme Référence sur la table « exploitants »

Dans la table « instruction » (dans une même vue), je peux ramener en « champs rapportés » les champs nom, date de naissance, forme juridique mais je ne peux pas ramener les données des 2 autres tables « dossiers » et « periodes_eligibilité »

Je viens de comprendre en écrivant et en testant :
je peux par exemple rapporter le champ surface_exploitée dans la table exploitants puis le rapporter dans la table « instruction »
OU
créer des vues supplémentaires à côté de ma table « instruction » sur les tables « dossiers » et « periodes_eligibilité » et voir les données par Pacage sélectionné à partir de la table « instruction »

Cela évite effectivement des Lookup un peu complexe à écrire (cas valeurs vides, …)

Dans mon cas, je n’ai utilisé que des références simples car mes relations sont du 1=>1 (dossiers => exploitants) ou n=>1 (periodes_eligibilité => exploitants)

Reste le problème d’import des mise à jour (très régulières) des tables « exploitants », « dossiers » et « periodes_eligibilité », des nouvelles lignes peuvent s’intercaler.

Comment procéder sans casser tous les liens ?

Merci d’avance
Bonne journée

4

Bonjour Emmanuel,

J’ai du mal à visualiser le sens de pacage ici.

Peux-tu m’expliquer l’utilité métier de ce champ ? Est-ce un référentiel unique ?

Quel est sa relation avec la autres tables ?
Ex :

  • un pacage est sur un et un seul exploitant ? (1-1)
  • un pacage peut contenir plusieurs exploitants ? (1-n)
  • plusieurs pacages sur un seul exploitant ? (n-1)
  • plusieurs pacages sur plusieurs exploitants (n-n)

Car je pense que dans ton exemple il te manque le référentiel propre aux pacages. Une table qui regroupe que les pacages (avec les champs qui en découlent) que tu viens ensuite ajouter relationnellement aux autres tables.

Cela te permettra ainsi de venir mettre à jour les tables indépendamment des autres, sans casser les liens. Pour cela, il faut bien que tu ais des références uniques sur chacune de tes tables afin de mettre à jour tes lignes proprement.

Si tu as des screens de tes tables (en anonymisant), cela pourrait aider :slight_smile:

Belle journée,
Victor

5

Bonjour Victor,
oui désolé.
le n° Pacage est l’identifiant unique d’un exploitant :

image
image540×619 26.2 KB

Dans mon modèle test (avec Références), je lie toutes mes autres tables par Référence sur la table Exploitants et c’est dans la table instruction_aa que je souhaite rapatrier des données (brutes ou avec formules) de toutes les tables.
La table exploitants est « le référentiel » des exploitants. Les autres tables utilisent le numéro Pacage comme identifiant. (relation 1-1 ou 1-n)

Je peux te donner accès à l’espace d’équipe mais je ne veux pas abuser de ton temps :
j’ai un dossier avec le modèle utilisant les Lookup et un dossier avec un modèle équivalent utilisant les références.

Je trouve le système avec références plus compliqué à mettre en œuvre, mais probablement parce que je ne saisi pas complètement la logique.

L’idée est de faire l’instruction 2026 de l’éligibilité des déclarants PAC sur Grist et de généraliser ensuite, si concluant, les projets ou tableurs partagés du service Agriculture de la DDT.

Et pour aller plus loin, mais c’est peut-être un peu ambitieux, gérer une partie du système d’information du service dans Grist, la limite étant pour l’instant le cloisonnement des tables dans les dossiers

Bonne journée

6

Bonjour Emmanuel,

A partir du moment où tu lies un pacage dans ta table instruction, je vois deux solutions :

  • Faire une vue liée
  • Lookup pour rattacher plus de données directement dans la table

Pour faire une vue liée, tu peux ajouter une vue à ta table de base (exemple Instruction) pour afficher toutes les données du pacage au clic sur la ligne instruction.

Pour cela, dans ta table ‹ Instruction › tu vas faire Nouveau → Ajouter une vue à la page. Tu choisis comment tu veux matérialiser cette vue (table, fiche etc…) et ensuite tu sélectionnes ta table ‹ Pacage ›. Enfin, bien choisir le bon champ dans le ‹ Sélectionné par ›. Tu peux ensuite l’ajouter à la page.

Voici un lien vers l’exemple : Pacage - Grist

Concernant la partie Lookup, tu peux certes rapatrier des colonnes dans d’autres tables, mais cela nécessitera de la maintenance en cas de changement.

Belle journée,
Victor

7

Bonjour Victor,
merci beaucoup pour tes explications.
Nous allons tester les 2 solutions en production, pour voir laquelle est la plus pratique pour notre usage.

Bonne journée