Avec la longue liste de nouvelles fonctionnalités publiées dans FileMaker Pro 17, un élément qui a attiré l’attention de mon geek intérieur est cette nouvelle fonction : Get(UUIDNumber). Cette nouvelle fonction est intéressante car elle permet désormais de stocker des UUID dans un champ de type numérique plutôt que dans un champ de type texte. Mon hypothèse est que le stockage de nombres dans la base de données pourrait occuper moins d’espace disque. (Je ne sais plus exactement d’où me vient cette idée, mais elle me suit depuis un moment… peut-être des spécifications techniques d’une ancienne version qui comparaient la taille minimale des nombres et du texte.)
Get(UUIDNumber)
La fonction Get(UUIDNumber) retourne un nombre unique de 24 octets (192 bits). Par exemple, vous pouvez utiliser cette fonction pour générer un identifiant unique d’enregistrement. Utiliser cette fonction à la place de Get(UUID) comme valeur calculée d’un champ clé primaire peut améliorer les performances des opérations basées sur les relations.
FM Help (source)
La documentation indique que la taille du résultat est fixe, mais lors de mes tests j’ai observé que la longueur du UUID retourné variait légèrement — j’ai obtenu des résultats de 57 et 58 chiffres. (Mesuré via le Data Viewer avec la fonction Length(Get(UUIDNumber)) — je n’ai pas pris le temps de compter manuellement les chiffres.)
Il pourrait y avoir d’autres améliorations de performance avec cette nouvelle fonction — peut-être une exécution plus rapide de la fonction elle-même ? Ou, comme indiqué dans l’aide, une amélioration des performances des relations. Je n’ai pas testé cet aspect, mais j’ai analysé la taille de stockage et la vitesse d’exécution.
Tests : j’ai commencé avec un nouveau fichier FileMaker Pro Advanced 17 vide : une table, un champ, et suppression de tous les champs par défaut. J’ai écrit un script pour créer 1 000 000 d’enregistrements. Pour chaque test, je partais d’un clone du fichier initial afin d’éviter toute “pollution” structurelle. Le layout utilisé ne contenait aucun champ — uniquement un bouton pour lancer le script. Le Script Workspace et le Data Viewer étaient généralement fermés pendant les tests.
Pour mesurer la taille finale du fichier, j’ai utilisé la taille affichée par le Finder macOS (“Get Info”) après fermeture du fichier. Les temps d’exécution ont été mesurés via Get(CurrentTimeUTCMilliseconds). Les tests ont été réalisés localement sur une machine récente : MacBook Pro 13” 2017, Intel Core i5 3,1 GHz, SSD.
J’ai également profité de ces tests pour explorer certaines hypothèses sur la performance de différents scripts (auto-enter, Set Field, boucles, etc.). Ces données ne sont pas détaillées ici mais figurent dans le tableau.
Voici les résultats :
Résumé des résultats :
| Temps moyen | Taille moyenne | |
| Get(UUIDNumber) | 126.3 | 91.27 Mo |
| Get(UUID) | 105.6 | 60.76 Mo |
J’ai été surpris : environ 33 % plus grand en taille et environ 16 % plus lent pour la nouvelle fonction numérique !
Pourquoi cette taille plus grande ? Selon la documentation FileMaker :
Retourne une chaîne unique de 16 octets (128 bits)…
Ce qui correspond à 36 caractères avec les tirets. Comparé aux 24 octets / 192 bits de la nouvelle version (57–58 caractères), cela représente environ 37 % de plus, ce qui correspond aux différences de taille observées. La version numérique nécessite plus de caractères pour garantir l’unicité.
Je pensais initialement que les champs numériques prendraient moins de place que les champs texte, mais c’est l’inverse ici à cause de la longueur des valeurs générées.
Concernant la vitesse, ce sont des résultats que les ingénieurs FileMaker pourraient probablement améliorer. Le temps moyen est d’environ 0,000117 seconde par enregistrement, génération et validation incluses.
Conclusion : la fonction texte Get(UUID) reste meilleure en termes de performance et de stockage. La seule vraie promesse de Get(UUIDNumber) serait une éventuelle amélioration des performances relationnelles.
Mise à jour après publication
J’ai effectué des tests supplémentaires pour vérifier mon hypothèse sur les champs numériques vs texte.
Test 1 : chaîne fixe “1234567890” en texte vs nombre 1234567890 en champ numérique (1 000 000 d’enregistrements). Résultat : tailles identiques (25,985 Mo) et temps similaires (~104s).
Test 2 : un seul chiffre (type booléen). Résultat : tailles identiques entre texte et numérique.
Je peux donc abandonner l’idée que les champs numériques sont plus compacts que les champs texte.
Cependant, d’autres facteurs existent comme l’indexation, qui peut influencer la taille globale et les performances.
Si vous avez des questions sur cet article, n’hésitez pas à nous contacter.
*Cet article a été initialement rédigé pour AppWorks, aujourd’hui intégré à Direct Impact Solutions. Il est fourni à titre informatif. Les informations sont exactes à la date de publication selon nos connaissances.
