FileMaker : Performance et mobilité (7)

Des données accessibles facilement et rapidement…

La performance se glisse partout dans la base de données, y compris là où cela ne se voit pas a priori !

On peut concevoir facilement en effet que pour que les données s’affichent rapidement, il faut un réseau rapide et des modèles peu chargés et réalisés selon les règles de l’art. Mais qui penserait à l’incidence des tables et du graphe des liens dans la rapidité d’affichage des données ?

Nous allons donc entrer dans les entrailles de votre base de données et la passer à la loupe…

Mais auparavant, rappelons dans les grandes lignes ce qu’elles sont !

Cet aspect caché de votre base FileMaker est caractérisé par un seul mot : « relationnel ». Vous réalisez une base de données relationnelle, c’est-à-dire une base (un fichier) dans laquelle les données sont en relation les unes avec les autres.

Et tout l’enjeu est là ! Et toute la difficulté aussi…

Car plusieurs questions se posent alors, à chaque nouvelle étape de conception de votre base :

• Quelles sont les réalités à mettre en lien ? C’est l’étape de définition des entités, et de création des tables…
• Qu’est-ce qu’on met en relation ? Dans quel contexte ? C’est l’étape d’élaboration du graphe des liens avec ses GOT et ses OT (1).
• On met en relation, mais comment ? C’est l’étape de création des liens, avec en amont, la définition des rubriques dont on a besoin pour cela…

Je n’entre pas dans les détails, ce n’est pas l’objet de cet article. Je vous renvoie à nos tutoriels qui traitent de ces sujets (2). Mais je m’appuie néanmoins sur ces notions rapidement évoquées pour expliquer en quoi la conception relationnelle de votre base a une incidence sur sa performance.

Fractionnez les tables

On pourrait dire qu’il s’agit de « diviser pour mieux régner » 😉

En effet, si vous travaillez en réseau, FileMaker passe son temps à transférer des données via le réseau : lorsque vous lancez la base de données depuis votre poste client et affichez un modèle, votre FileMaker client interroge le FileMaker Server distant et lui demande d’afficher la base de données X, le modèle Y et toutes les données contenues dans ce modèle. Votre poste télécharge donc en quelques sortes toutes ces informations.

Puis, vous modifiez une rubrique.

Dans ce cas, l’information, mais aussi la totalité du contenu de l’enregistrement, est transférée depuis votre poste client vers le poste serveur.

Dans le même temps et sans que vous ne vous en rendiez compte, de petites notifications sont envoyées à tous les autres utilisateurs, signalant l’obsolescence des données de cet enregistrement. Si l’un de vos collègues avait déjà travaillé dessus et qu’il y revient après que vous l’ayez modifié, c’est l’enregistrement entier, et pas seulement la modification apportée, qui est téléchargée à nouveau !

Cela veut donc dire que des enregistrements entiers circulent en permanence sur le réseau !

Cela veut dire aussi que plus ces enregistrements ont des données, plus ce transfert est lourd… et donc lent !

Mais la quantité de données ici n’est pas à envisager uniquement du point de vue du nombre d’enregistrements contenus dans une table… Puisqu’il s’agit de transférer les données D’UN SEUL ENREGISTREMENT À LA FOIS, ce qui est en jeu ici, c’est le nombre et la nature des rubriques contenues par la table.

Plus votre table contient de rubriques, plus les enregistrements seront longs à transiter via le réseau.

Plus votre table contient de rubriques au contenu volumineux (multimédia, textes longs), plus il en sera de même !

FileMaker inc. conseille même de fractionner de telles tables de sorte qu’une table contienne les rubriques fréquemment sollicités et une autre celles volumineuses… Dans ce cas, il faut créer un lien 1 à 1 entre ces deux « tables » dans le graphe des liens (3)… Nous remarquons alors qu’elles sont distinctes uniquement pour des raisons techniques, ce qui dans les faits, est très inhabituel !

La plupart du temps (mais pas toujours), les tables représentent une entité distincte. Ce que ne fait pas par exemple une feuille de calcul Excel. Dans une feuille de calcul, vous trouverez des données qui, par exemple, indiquent l’identité des personnes puis, sur les mêmes lignes, des données concernant des factures. Or, il faut séparer ces deux types de données en deux tables, que l’on met ensuite en relation, pour qu’à telles personnes correspondent bien telles factures… On évite alors, lorsqu’on modifie le nom d’une personne, que les informations sur l’une ou l’autre facture qui la concerne, transite également par le réseau…

La semaine prochaine, nous entrerons un peu plus en avant dans le graphe des liens pour voir quelle est la bonne pratique à adopter 😉

En attendant, je vous souhaite à tous une bonne semaine. Portez-vous bien et bonnes performances filemakeuriennes

Marie-Charlotte Potton

(1) GOT : Groupement d’occurrences de table – OT : Occurrences de table.

(2) Voir les fiches Astuces 100 et 101, l’eBook Les Essentiels Tables, occurrences de tables et graphe des liens et surtout, le module 2 de la formation Personne Ressource FileMaker.

(3) Je pense que ce genre de séparation est surtout à pratiquer dans le cadre d’une solution utilisée dans un contexte de mobilité… Le fait de diviser de la sorte une table en deux tables alourdit la lisibilité du graphe des liens…

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

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