FileMaker : Performance et mobilité (8)

Aimez-vous les spaghetti ?

La question peut paraître incongrue sur un blog dont le propos n’a rien à voir avec la gastronomie !

Pourtant, ceux qui nous suivent depuis longtemps savent déjà où je veux en venir 😉

Car ce plat savoureux se glisse dans la structure même de FileMaker, et concerne aussi le sujet de la performance des solutions développées avec FileMaker sous l’angle abordé la semaine dernière, celui de sa structure…

Nous avons vu lundi dernier que pour mieux régner, il était préférable de diviser… les tables de vos solutions.

Maintenant, il s’agit de les organiser dans ce que nous appelons dans notre jargon, le graphe des liens…

Le graphe des liens ?

Mais auparavant, rappelons de quoi il s’agit.

Nous avons vu que les tables dans FileMaker rassemblent des données concernant le plus souvent des entités (par exemple, des personnes, des factures, etc.) saisies dans des rubriques.

Or, et c’est tout l’intérêt du relationnel, il s’agit de mettre en relation ces données. Cela n’a en effet aucun sens d’avoir, dans une base de données, des personnes et des factures si ces deux entités ne communiquent pas !

Le graphe des liens est une représentation graphique de ces relations.

On y trouve comme des alias ou raccourcis des tables, alias ou raccourcis que l’on appelle « Occurrences de table » (OT). Et, par un simple glissé-relâché de souris, on associe une rubrique d’une OT à une rubrique d’une autre OT… Et par une fenêtre de définition, on peut modifier ou préciser ce que l’on vient de faire par la souris (1).

En soi, rien bien de compliqué au niveau des manipulations, mais les choses sont plus corsées sur le plan de la conception : quelles OT lier et avec quelles rubriques et quelles options ? C’est bien là toute la question… mais ce n’est pas la seule…

De dépendances en dépendances…

Lorsque vous créez votre base de données relationnelle, vous créez d’abord une première table, la table Personne par exemple. Puis vous souhaitez attribuer des numéros de telecom à ces personnes et comme vous avez compris le principe et l’intérêt du relationnel, vous créez une table Telecom que vous liez à la table Personne. Vous faites de même avec une table Adresse, voire même une table Pays liée aux adresses (grâce à cette table, vous gérez les noms des pays ainsi que leurs particularités en termes de taxes)… et ainsi de suite…

Et de file en aiguille, votre graphe des liens s’enrichit de nouvelles OT et de nouveaux liens, qui s’ajoutent aux liens précédemment créés…

Comme FileMaker n’a aucune limite (ou presque), vous n’en avez pas non plus… et votre graphe des liens finit par ressembler à… un plat de spaghetti !

Vous voyez, je vous avais dit qu’on en parlerait !

Bien entendu, ici, on ne fait pas référence à la saveur de ce fameux plat italien mais bien à son aspect disons, un peu embrouillé 😉

Difficile de s’y retrouver dans un tel embrouillamini de liens ! Et dites-vous bien que si vous, vous avez de la peine à vous y retrouver, il y a de fortes chances pour qu’il en soit de même pour FileMaker !

Et là, je suis obligée de faire appel à une nouvelle notion pour que vous compreniez pourquoi la manière dont votre graphe des liens est organisé a une incidence versus performance de votre solution.

Tout lien suppose et crée un lien… de dépendance. Par exemple : une facture créée pour une personne et utilisant le lien existant entre Personne et Facture dépend de la personne à partir de laquelle elle est créée et à laquelle elle reste attachée. Lorsque vous affichez dans une table externe tous les factures d’une personne, ces factures le sont grâce à cette relation de dépendance qui les lie à cette personne. On fait de même appel à cette dépendance pour certaines options, comme celle de supprimer tous les enregistrements liés lorsque l’enregistrement source (de l’OT liée) l’est ou encore, lorsqu’on utilise une rubrique liée dans un calcul.

FileMaker donne la possibilité, par ce lien de dépendance, d’utiliser des données de rubriques appartenant à une rubrique liée au Nième degré. Il est évident que plus l’OT liée est éloignée de l’OT qui fait appel à ces données, plus le chemin est long, plus elles sont longues à nous parvenir !

Une carte pour se repérer…

Mais en fait, c’est pire que cela !

Si vous imaginez que FileMaker va aller droit au but, c’est-à-dire suivre tout le cheminement logique qui le mène de Personne à Facture (par exemple), sans aller voir ce qui se passe du côté de Telecom, d’Adresse, de Pays, ou de toute autre OT présente dans votre graphe des liens et liée d’une manière ou d’une autre à Personne, vous avez tout faux 😟 !

Bien sûr qu’il va y aller ! Mais auparavant, pour trouver la rubrique que vous lui indiquez, il va absolument tout exploré, même si la rubrique liée est tout près de Personne grâce à un lien de premier degré !

Imaginez que vous êtes un explorateur.

On vous a donné un objectif : vous rendre à tel lieu-dit. Vous ne connaissez ni ce lieu ni le chemin qui y mène. Vous avez tout au plus une carte, qui vous donne des indications, mais non le lieu-dit que vous recherchez, et celui-ci n’existe pas pour les GPS. Qu’allez-vous faire alors ? Prendre votre courage à deux mains, vous chausser d’une bonne paire de chaussures et partir à l’aventure sur tous les chemins qui s’ouvrent devant vous, en les prenant un à un pour trouver enfin votre fameux lieu dit… quitte à faire de très longs détours pour trouver ce qui au final, était tout près de votre point de départ !

Imaginez maintenant qu’en vous donnant la carte et le nom du lieu-dit, on vous indique un périmètre géographique où rechercher… Déjà, vous respirez : la recherche, au lieu de durer plusieurs semaines, ne prendra que quelques jours, le temps de prendre un à un tous les chemins de la zone géographique indiquée 😉

Pour FileMaker, il en est en gros de même.

Pour afficher une table externe, un enregistrement lié, supprimer des enregistrements liés, effectuer des calculs avec des données liées, de manière cachée, FileMaker consulte une « carte schématique »correspondant à votre graphe des liens.

Si votre graphe des liens est du type Spaguetti, avec de nombreuses OT ajoutées les unes aux autres, cette carte est très lourde et gourmande en performances.

La bonne pratique est alors encore une fois de diviser pour mieux régner, quitte à répéter plusieurs fois des OT. Avec ces OT, on crée des GOT, c’est-à-dire des « Groupements d’Occurrences de Table », qui délimitent un contexte (zone géographique…) propre à chaque modèle ou groupe de modèle.

Par exemple, pour le modèle Personne, on aura le GOT Personne, avec principalement l’OT Personne, et secondairement des OT qui dépendent directement de Personne : Telecom, Adresse et Pays, Produits… Et le modèle Liste_Personnes appartient au même GOT, même s’il affiche un peu moins d’informations que le modèle formulaire Personne.

Si l’on veut connaître le détail des produits, on change alors de modèle et de contexte pour se rendre sur le modèle Produit, qui prend appui sur le GOT Produits, avec principalement l’OT Produit, et secondairement des OT qui dépendent directement de Produit : Personne, Telecom (mais non Adresse), Transaction…

Dans ce type d’organisation, FileMaker ne cherchera l’information que dans le GOT du modèle actif. Sa zone géographique est alors bien délimitée et il perd beaucoup moins de temps et d’énergie à chercher dans cette zone plutôt que sur l’ensemble du graphe des liens 👍 (2) …

Nous en avons fini avec la structure, du moins pour ce que nous souhaitions aborder dans cette série d’articles. Je vous propose dès la semaine prochaine de nous attaquer aux calculs… en prenant d’abord conscience qu’ils sont partout dans nos bases…

Alors, portez-vous bien et bonne semaine à tous !

Marie-Charlotte Potton

(1) Pour compléter de manière théorique et pratique cet article, voir l’eBook Les Essentiels Tables, occurrences de tables et graphe des liens et le pack de fiches Astuces sur le Graphe des liens.

(2) Ce que nous venons de décrire correspond à l’organisation du graphe des liens sous forme d’ancre – bouées. Pour en savoir plus sur le sujet, voir les tutoriels cités dans la note ci-dessus.

Premier article – Article précédent – Article suivant

Tags: Graphe des liens, interface, Mobilité, Performance