Ajouter une recherche multi-tables
Objectif
Ajouter un champ qui pointe vers un enregistrement de l’une de plusieurs tables — un Client qui peut être un Compte ou un Contact, un Payeur qui peut être l’une de quatre choses.
Prérequis
- Vous êtes connecté avec un rôle de créateur (ou d’administrateur de la plateforme).
- La table à laquelle vous ajoutez le champ existe, ainsi qu’au moins deux tables vers lesquelles il doit pouvoir pointer.
Étapes
- Ouvrez Tables, choisissez l’environnement et ouvrez votre table sur l’onglet Champs.
- Sélectionnez Nouveau, et donnez au champ un nom d’affichage et un nom logique comme d’habitude.
- Pour le type de données, choisissez Recherche (plusieurs tables).
- Cochez les tables vers lesquelles le champ peut pointer. Au moins deux. Un petit numéro à côté de chaque table cochée indique l’ordre dans lequel vous les avez cochées — c’est l’ordre que verra l’utilisateur, et la première est celle sur laquelle s’ouvre le sélecteur. Cochez d’abord la plus courante.
- Sélectionnez Ajouter.
- Le champ est opérationnel dès son ajout — comme pour tout champ, sa colonne existe immédiatement.
Ce que voit l’utilisateur
Une zone de recherche ordinaire. La sélectionner ouvre un panneau, en tête duquel figurent les tables que vous avez cochées, au-dessus des noms qu’elles filtrent :
Customer
[ 👤 Ada Lovelace ] ← closed: the record, with its table's icon
─────────────────────────────
[ Account ] [ Contact ] ← open: the tables you ticked, in your order
Ada Lovelace ← …and the matches in whichever is selected
Ada Byron
Choisir d’abord la table n’est pas une étape de plus pour le principe. « Trouve-moi un contact nommé Ada » et « trouve-moi un compte nommé Ada » sont deux recherches différentes sur deux ensembles de colonnes différents : une liste de résultats fusionnée devrait réconcilier des colonnes qui ne se correspondent pas. Nommer la table d’abord signifie que tout ce qui se trouve en dessous est le champ de recherche qui fonctionne déjà — sa recherche, ses secondes lignes, ses images, sa grille de Recherche avancée.
Les tables se trouvent dans le panneau plutôt qu’au-dessus de la zone : elles n’occupent donc aucune place sur le formulaire quand personne ne fait de choix. C’est pourquoi un enregistrement choisi affiche l’icône de sa table à côté de lui : le sélecteur de table étant hors de vue, c’est l’icône qui indique encore si Ada est un compte ou un contact. C’est l’icône que vous avez donnée à la table dans le concepteur de tables : donnez donc des icônes distinctes à vos tables si elles doivent partager une recherche multi-tables.
Changer de table efface le choix, délibérément : l’identifiant d’un contact n’est pas celui d’un compte.
Ce qui est stocké
Deux choses, dans deux colonnes : l’identifiant de l’enregistrement, et la table dans
laquelle il se trouve. Vous verrez la seconde si vous interrogez directement la table —
c’est le nom de votre colonne suivi de _type, et elle contient le nom logique de la table.
C’est la même forme que celle que la plateforme utilise déjà pour le propriétaire d’un enregistrement, et c’est pourquoi ce champ est un type de données distinct plutôt qu’une Recherche avec une liste de cibles plus longue.
Le seul vrai compromis : pas de clé étrangère
Une Recherche ordinaire reçoit une vraie clé étrangère en base de données : la base elle-même refuse que l’enregistrement vers lequel elle pointe soit supprimé sous ses pieds. Une recherche multi-tables ne peut pas en avoir — une seule colonne ne peut pas référencer plusieurs tables —, donc :
- La plateforme vérifie toujours, à chaque enregistrement, que l’enregistrement choisi existe.
- Mais si quelqu’un supprime cet enregistrement par la suite, rien ne l’en empêche. Le champ affiche alors la référence brute au lieu d’un nom, ce qu’affiche aussi une recherche ordinaire dont la cible a disparu : c’est visible, pas silencieux.
- La suppression d’une table entière reste bloquée tant qu’une recherche multi-tables la liste comme cible, comme pour une recherche ordinaire.
Si vous n’avez besoin que d’une seule table, utilisez une Recherche simple. Vous obtenez la clé étrangère, et le concepteur vous le signale plutôt que de vous laisser construire par mégarde une colonne moins robuste.
Les onglets associés fonctionnent toujours
Chaque table cochée reçoit sa propre relation : un enregistrement de n’importe laquelle d’entre elles propose donc un onglet Associés qui liste les enregistrements pointant vers lui. Un formulaire Compte affiche ses Clients ; un formulaire Contact aussi. Rien de plus à configurer.
Le propriétaire en est un
Le Propriétaire d’un enregistrement est une référence multi-tables — une personne ou une équipe — et il s’affiche avec ce même contrôle sur tout formulaire qui place le champ Propriétaire. Y choisir un nouveau propriétaire a le même effet que la commande Attribuer, et passe par les mêmes vérifications ; voir Changer le propriétaire d’un enregistrement.
Dépannage
- « Tick at least two tables. » — avec une seule cible, c’est une Recherche ordinaire qui a renoncé à sa clé étrangère pour rien. Choisissez plutôt Recherche.
- Les tables sont grisées quand j’ouvre un champ existant. — la liste des cibles est figée une fois le champ créé, pour la même raison que la cible unique d’une Recherche : des enregistrements contiennent déjà des références vérifiées par rapport à cette liste, et retirer une table laisserait certaines d’entre elles pointer vers quelque chose que le champ déclare ne pas pouvoir atteindre. Supprimez le champ et ajoutez-le de nouveau.
- Le sélecteur affiche des noms logiques au lieu des noms de tables. — la liste des tables de l’environnement n’est pas encore chargée. Elle se résout un instant plus tard ; sinon, rouvrez le formulaire.
- Le champ affiche quelque chose comme
contact:9f2c…au lieu d’un nom. — l’enregistrement vers lequel il pointe a été supprimé. Choisissez-en un autre. - Une table que je veux n’est pas dans la liste. — la table du champ elle-même est exclue, comme pour une Recherche ordinaire. Tout le reste de l’environnement est proposé.