AcumatiCares
Introduction
Dans une application de base de données, les clés de table jouent un rôle important. De plus, lorsque vous concevez de nouveaux écrans ou même un module, la décision sur le schéma clé à utiliser influencera non seulement la façon dont vous codez vos DAC , mais influencera également dans une certaine mesure la facilité d’utilisation et d’intégration de votre application. Dans les premiers jours de travailler avec Acumatica, j’avais l’habitude de me gratter la tête beaucoup sur la prise de décisions dans le choix de mes clés ou comment utiliser une pièce d’identité par rapport à un CD dans les demandes génériques.
Pourquoi vous devriez vous en soucier
Décider de modifier la clé primaire de l’une des tables est très difficile une fois que vous avez installé l’application sur d’autres sites, ce qui signifie généralement que vous devrez vivre avec votre choix pendant très longtemps - sinon pour toujours. Avant d’aller plus loin, définissons ce que nous entendons par clés[1].
Clé primaire (PK) : colonne ou groupe de colonnes dans une table qui identifie de manière unique chaque ligne de cette table. Les clés primaires ne peuvent pas être des doublons, ce qui signifie que la même valeur ne peut pas apparaître plus d’une fois dans la table. Une table ne peut pas avoir plus d’une clé primaire.
Clé candidate : Il s’agit également d’une clé unique pour identifier un enregistrement de manière unique dans une table, mais une table peut avoir plusieurs clés candidates. Des exemples de clés candidates typiques sont les e-mails, le nom de l’entreprise, l’ID de l’employé, DUNS[2] Number.
Clé alternative : colonne ou groupe de colonnes dans une table qui identifie de manière unique chaque ligne d’une table particulière. Une table peut avoir plusieurs choix pour une clé primaire, mais une seule peut être définie comme clé primaire. Toutes les clés qui ne sont pas la clé primaire sont appelées clés alternatives.
Clé naturelle: Colonne ou groupe de colonnes d’une table qui identifie de manière unique chaque ligne de cette table d’une manière humainement reconnaissable. Un code ou un numéro de document est souvent appelé clé naturelle.
Clé de substitution: Une clé artificielle qui vise à identifier de manière unique chaque enregistrement est appelée une clé de substitution. Ce type de clé est utilisé lorsque vous n’avez pas ou ne voulez pas utiliser une clé naturelle comme clé primaire.
Foreign Key (FK) : colonne ou groupe de colonnes dans une table qui est la clé primaire d’une autre table.
Différence entre la clé et l’index
Comme mentionné précédemment, une clé est une colonne ou un groupe de colonnes ou un groupe de valeurs si vous voulez. Un index, en revanche, aide les bases de données à localiser l’emplacement physique où la ligne est stockée en fonction des valeurs fournies par la clé. Par conséquent, l’index est comme un dictionnaire de clés par rapport aux emplacements. La base de données utilise l’index pour trouver rapidement la ligne liée aux valeurs de clé.
Quel schéma utiliser
Certaines applications de base de données utilisent souvent un seul schéma (type) pour identifier les clés. Dans le passé, j’ai travaillé avec un ERP qui utilisait des GUIDs comme toutes leurs clés, un autre utilisait uniquement des clés naturelles tandis qu’un troisième n’utilisait que des entiers de substitution. Chacun, comme nous le verrons, a ses avantages et ses inconvénients. Acumatica utilise plusieurs schémas pour les clés de table en fonction des besoins et du contexte, ce qui rend difficile le choix de l’un plutôt que de l’autre, mais ils ont tous leur place dans la base de données. Mais commençons par la plus simple des clés et travaillons notre chemin vers les plus complexes.
La clé naturelle
Une clé naturelle est une valeur simple (telle que la chaîne) qui identifie clairement la signification de la ligne. Si je dis par exemple « US », « CA » ou « MX », vous savez instantanément de quoi je parle des pays. Si je dis « H0H 0H0[3] » ou « 90210[4] », vous les connaissez probablement aussi - bien que ce soit un peu plus difficile. Enfin, si je dis « NON TAXABLE », je n’ai rien à expliquer. Bien qu’il soit rare de nos jours que quoi que ce soit ne soit pas imposable, en soi.
Avantages: Hautement reconnaissable, plus facile à comprendre, plus court que les autres, donne un contexte d’utilisation, plus facile à utiliser dans les requêtes de base de données.
Inconvénients: La taille (généralement fixe) doit être décidée à l’avance afin qu’ils ne puissent pas se développer plus facilement. Les petites tailles conduisent à être des codes méconnaissables. Une fois que la clé a été enregistrée, elle ne peut pas être changée sans difficulté.
La clé entière de substitution
L’entier de substitution est l’une des clés les plus utilisées dans les applications de base de données. Ils prennent très peu d’espace (généralement 32 bits), peuvent augmenter automatiquement, et le nombre de lignes peut être assez important (environ 2 à 4 milliards selon si signé ou non). Une telle clé sera visible ou non en fonction de son utilisation.
Avantages: Stockage efficace et accès à la base de données, la plupart des tables ont un petit nombre de lignes, Ce qui signifie que les clés sont plus faciles à lire et à utiliser dans les requêtes, auto-incrémentable, modèle simple, et aimé par la plupart des développeurs.
Inconvénients: Leurs valeurs ne sont pas faciles à reconnaître, nécessitent généralement une table jointe pour comprendre la signification. Une fois que la clé a été enregistrée, elle ne peut pas être changée facilement, voire pas du tout.
Convient pour:
- Tableaux avec de nombreuses lignes
- Tableau pour le traitement des lignes
- Séquences de lignes ordonnées
En voici quelques exemples :
La clé GUID de substitution
Un identificateur universel unique (UUID) ou un identificateur unique global (GUID) est une valeur de 128 bits (16 octets) qui est normalement divisée en cinq groupes de longueurs variables. Le GUID de substitution est largement utilisé dans de nombreuses applications de base de données. Sa force réside dans son universalité et sa probabilité presque nulle de collision. Ils sont uniques non seulement sur un système donné, mais dans tous les systèmes. Cela les rend idéaux pour l’échange de données ou d’applications personnalisées entre les systèmes. Veuillez noter qu’il existe plusieurs variantes définies par la norme RFC 4122, mais nous n’en discuterons pas ici. D’autres GUID non conformes existent également.
Avantages: Universel et unique en raison de leur nature. Ils sont bien documentés et normalisés. Leur nature méconnaissable en fait un bon candidat pour les références « secrètes ». Compte tenu d’un GUID, il est pratiquement impossible de deviner une valeur future, bien que certaines variantes soient plus faibles à cet égard.
Inconvénients: Ils sont difficiles à écrire et impossibles à retenir. Par conséquent, vous devez utiliser une instruction join ou une action de copier-coller pour les utiliser pour les requêtes de base de données. Leur valeur est pratiquement méconnaissable, de sorte qu’ils ne donnent aucun contexte de leurs utilisations spécifiques.
En voici quelques exemples :
Qu’en est-il des clés Acumatica?
Acumatica a fait un excellent travail pour choisir ses clés, bien qu’il puisse ne pas sembler de cette façon à première vue.
La clé naturelle
De nombreuses tables Acumatica utilisent une clé naturelle lorsque cela est approprié.
En voici quelques exemples :
Convient pour:
- Noms de code (TaxZoneID, TermsID, CountryID, StateID, etc.)
- Noms de classe (ItemClassID, CustomerClassID, etc.)
- Documents (SOOrder.OrderType, SOOrder.OrderNbr, GLDocBatch.Module, GLDocBatch.BatchNbr, etc.)
La clé entière de substitution améliorée
Quand j’ai commencé avec Acumatica, ce schéma clé était assez intrigant pour moi jusqu’à ce que je comprenne vraiment la puissance derrière elle. Ce schéma clé est composé de 2 parties:
- La vraie clé de substitution, alias l’ID, qui est la vraie clé physique de la table (dans la plupart des cas, un entier de 32 bits mais parfois un entier de 64 bits).
- La clé naturelle visible, c’est-à-dire le CD, est la clé qui est visible pour l’utilisateur.
L’idée derrière cela est que la table utilise l’ID entier avec tous ses avantages tandis que l’utilisateur voit le CD avec tous ses avantages. L’astuce derrière le rideau ici est que la table physique utilisera l’ID comme clé, mais le DAC (Data Access Class) utilisera le CD comme clé afin de commander les lignes à l’écran par CD au lieu d’ID. Cela permet à l’utilisateur de naviguer d’un CD à l’autre de manière naturelle tout en conservant la table avec une clé entière. En outre, toutes les clés étrangères référençant la table utiliseront l’ID comme FK physique, mais afficheront à nouveau le CD pour l’utilisateur. Ce schéma est utilisé pour les tables les plus importantes telles que tous les comptes d’entreprise (clients, fournisseurs, succursales, entreprises, employés) mais aussi les tables les plus utilisées (poste d’inventaire, entrepôts, comptes GL, sous-comptes, projets, tâches, actifs, itinéraires, etc.).
L’autre fonctionnalité intéressante de ce schéma est que l’utilisateur peut également modifier le CD lié à l’ID à l’aide d’un id change d’appel d’action globale. En utilisant cette action, l’utilisateur est en mesure de « recoder » les clés à mesure que l’entreprise et la mise en œuvre progressent.
Convient pour:
- Comptes d’entreprise (principalement parce que vous voudrez peut-être modifier la clé plus tard)
- Clé modifiable des tableaux largement utilisés
Dans les 2 TSGI suivants, remarquez comment la clé physique de la table (voir le [BAccount_PK] dans BAccount Table) est différente de la clé DAC (voir IsKey = true dans le champ AcctCD ).
Voir l’utilisation de l’action CHANGE ID :
La clé GUID de substitution améliorée
Très similaire à son homologue entier, ce schéma de clé est composé de 2 parties:
- La vraie clé de substitution, alias l’ID, est la vraie clé GUID physique de la table.
- La clé naturelle visible, généralement un nom de chaîne, est la clé qui est visible pour l’utilisateur.
Convient pour:
- Références d’objet système
- Identificateurs globaux de valeurs partagées
Dans les 2 TSGI suivants, remarquez comment la clé physique de la table (voir le [WebHook_PK] dans la table WebHook) est différente de la clé DAC (voir IsKey = true dans le champ Nom ).
Contrairement à l’ID /CD typique, les écrans utilisant ce schéma n’ont pas d’action globale pour CHANGER L’ID bien qu’un puisse facilement être créé.
La clé de détail
Une clé de détail est une clé utilisée pour une table qui représente les enfants d’une autre table. En règle générale, vous prenez la table récapitulative (le parent) et y ajoutez un autre champ clé. Encore une fois, plusieurs modèles existent, et nous verrons lequel est favorisé.
Le simple
Une conception simple pour ce type de clé de détail consiste à prendre la touche Résumé et à ajouter la valeur de la clé candidate principale pour le détail. Cette conception (assez rare) ne doit être favorisée que si vous souhaitez simplifier l’unicité de votre clé mais sans avoir les avantages de la prochaine conception.
Exemples : GITable, CashAccountDetail, État
Le bien
Une bonne conception pour les touches de détail consiste à prendre la touche Résumé et à y ajouter un LineNbr. Acumatica favorise que dans la majorité des cas pour de multiples raisons:
- C’est facile: juste un simple entier et voilà
- C’est automatisé: en utilisant le LineNbrAttribute, vous pouvez générer automatiquement le LineNbr.
- Il est triable et glisser/droppable : si votre DAC implémente ISortable ET que vous utilisez un PXOrderedSelect
- Il permet des « doublons » lors de l’examen de la clé candidate principale qui se trouve généralement sur la ligne de détail (InventoryID par exemple)
- Il autorise les valeurs Null pour les clés candidates, ce qui rendrait généralement la clé unique
Exemples : SOLine, POLine, ContractDetail, ARTran, APTran, GLTran, etc.
Le partagé
Un autre choix de conception intéressant pour une table de détails est de ne pas utiliser du tout la clé de résumé et de créer une clé faite avec un entier de substitution et d’ajouter le NoteID du résumé comme le « parent ». Cette conception permet à la table de détails (telle que CRRelation) d’être partagée par plusieurs autres tables récapitulatives (telles que CRLead, CRCase, CROpportunity, CRContact, BAccount, etc.). Cependant, cela nécessite généralement une version spéciale de PXSelect (telle que CRRelationsList) pour gérer la relation avec le parent.
Exemple : CRRelation
Conclusion
J’espère que j’ai aidé un peu à percer le mystère derrière le choix des clés dans Acumatica. Ce qu’il est important de se rappeler, c’est que « Taille unique » ne s’applique pas à Acumatica. L’utilisation d’une clé naturelle, bien que le schéma le plus facile à utiliser, n’est pas le meilleur choix pour tous les contextes.
Au fil du temps, j’ai remarqué que si vous comprenez les clés d’une application, vous comprendrez beaucoup de choses avec un seul regard.
Bonnes questions à vous tous.
____________________________
Notes de bas de page
[1] Étant donné qu’Acumatica est une application multi-locataires, ses clés de table incluent presque toujours un champ CompanyID . Nous ignorerons ce fait par souci de simplicité.
[2] Le système de numérotation universel de données, abrégé en DUNS ou D-U-N-S, est un système propriétaire développé et géré par Dun & Bradstreet qui attribue un identifiant numérique unique, appelé « numéro DUNS » à une seule entité commerciale.
[3] Code postal du Père Noël (au Canada évidemment).
[4] Une célèbre série télévisée américaine pour les personnes âgées comme moi.
