Conception d'architecture 4D : un guide complet

La conception architecturale 4D est le processus de structuration d’une base de données 4D (ses tables, champs, relations, index et niveaux d’accès) afin que l’application reste rapide, maintenable et sécurisée au fur et à mesure de sa croissance. Un schéma 4D bien planifié implique généralement cinq décisions principales : la granularité des tables, la stratégie relationnelle, le type de clé primaire, l’emplacement de l’index et la séparation des données de la logique de l’interface. Bien faire les choses dès le début vous aidera à éviter des migrations coûteuses à l’avenir.

Points clés à retenir

• La conception de l’architecture 4D sépare trois préoccupations : le modèle de données (tables, champs, relations), la couche de logique métier (méthodes, classes, déclencheurs) et la couche de présentation (formulaires, zones de liste, boîtes de dialogue).
• Le type de relation compte plus que le nombre de tables : un lien plusieurs-à-plusieurs nécessite une table de jonction, tandis qu’un lien un-à-plusieurs utilise un champ de clé étrangère plus une relation.
• Les index accélèrent les lectures mais ralentissent les écritures : indexez les clés étrangères et tout champ utilisé dans la clause WHERE d’une requête, pas tous les champs.
• La couche ORDA (Object Relational Data Access) de 4D change votre perception du schéma : les tables et les champs bien nommés deviennent des noms de classes de données et d’attributs lisibles dans le code.
• Le déploiement client-serveur par rapport au déploiement mono-utilisateur est une décision architecturale et non un déploiement après coup : cela affecte le verrouillage, la mise en cache et la façon dont vous écrivez des requêtes.
• Les conventions de dénomination appliquées de manière cohérente dès le premier jour permettent de gagner plus de temps de refactorisation que toute autre habitude.

Que signifie « Architecture 4D » dans un contexte de base de données

La conception d’architecture 4D fait référence à la conception structurelle d’une application construite sur la plateforme 4D (4e Dimension), l’environnement de base de données relationnelle et de développement low-code initialement publié par l’équipe de Laurent Ribardière en 1984 et désormais maintenu par 4D SAS. Contrairement à une base de données SQL pure, 4D regroupe le moteur de données, un langage de programmation, un concepteur de formulaires et un serveur web/REST dans un seul produit — donc « l’architecture » ici couvre à la fois le schéma et les couches d’application qui le recouvrent.

Le terme est parfois confondu avec la visualisation architecturale (BIM 4D, le temps comme quatrième dimension dans la conception des bâtiments). Ce guide couvre le sens logiciel : comment agencer une base de données 4D et ses couches applicatives. Si vous êtes arrivé à la recherche de conception de bâtiments, les concepts ci-dessous ne s’appliqueront pas.

Les trois couches d’une application 4D

Les projets de conception d’architecture 4D bénéficient d’un modèle en couches explicite. Le partage des responsabilités empêche une application en pleine croissance de se transformer en un enchevêtrement de scripts de formulaire.

Couche 1 — Le modèle de données

Le modèle de données est l’ensemble des tables, champs, relations et index stockés dans le fichier de structure 4D. Cette couche ne doit contenir aucun code d’interface utilisateur ni aucune règle métier qui pourrait résider ailleurs. Les types de champs (texte, entier, réel, date, heure, booléen, blob, objet, image) et les longueurs de champ sont fixes ici, et leur modification ultérieure sur une base de données en direct nécessite du soin.

Couche 2 — Logique métier

La logique métier réside dans les méthodes de projet, les classes et les déclencheurs de table. Dans 4D moderne, les classes (introduites avec 4D v18 R3 et développées depuis) ​​vous permettent d’écrire du code réutilisable et testable plutôt que de disperser la logique entre les méthodes de formulaire. Un déclencheur sur une table se déclenche lors de la création, de l’enregistrement et de la suppression - utile pour les pistes d’audit, mais un déclencheur qui appelle l’interface utilisateur sera interrompu dans les contextes de serveur sans tête.

Connexes : Airtable — Une interface simple sous forme de feuille de calcul reposant sur une véritable base de données relationnelle, avec des automatisations, des vues et des interfaces partageables..

Couche 3 — Présentation

La présentation couvre les formulaires, les zones de liste, les boîtes de dialogue de saisie et toute sortie Web ou REST. Les formulaires 4D se lient directement aux champs et aux variables, ce qui est pratique mais encourage à mettre de la logique dans le formulaire. Garder les méthodes de formulaire légères (appeler une méthode de classe et afficher le résultat) est le plus grand gain de maintenabilité dans la plupart des projets 4D.

Conception du modèle de données : tables, relations et clés

Les décisions de modélisation des données dans la conception d’une architecture 4D suivent des principes relationnels, auxquels s’ajoutent des mécanismes spécifiques à 4D.

Choisir la granularité des tables

Une table doit représenter un type d’entité. Diviser une table « client » en « client » et « adresse_client » est logique lorsqu’un client peut avoir plusieurs adresses ; les fusionner a du sens lorsqu’il y a exactement une adresse par client et aucune réutilisation. Une normalisation excessive dans de nombreuses petites tables augmente le nombre de relations et de jointures, ce qui nuit aux performances dans les vues de liste.

Si vous faites du shopping : Zoho Creator — Un créateur d'applications low-code qui se connecte à la suite Zoho plus large et propose des tarifs par utilisateur plutôt que par application..

Types de relations

4D prend en charge les relations automatiques définies dans l’éditeur de structure et les relations manuelles créées dans le code. Les modèles courants :

Relation	Implémentation 4D	Utilisation typique
Un à plusieurs	Champ de clé étrangère du côté « plusieurs » plus une relation	Facture → Lignes de facture
Plusieurs à plusieurs	Table de jonction avec deux clés étrangères	Produits ↔ Fournisseurs
Un à un	Clé primaire partagée ou clé étrangère unique	Utilisateur → Profil utilisateur
Auto-référencement	Clé étrangère pointant vers la même table	Employé → Gestionnaire

Stratégie de clé primaire

4D propose des clés primaires longint à incrémentation automatique et des clés primaires UUID (texte). Les clés longues sont compactes et rapides à indexer ; Les UUID sont uniques au monde, ce qui est important lors de la fusion de données de plusieurs sites ou de la synchronisation avec des systèmes externes. Un compromis courant est une clé interne longint et un champ de texte distinct et unique de « référence externe ».

Indexation et performances des requêtes

Les index constituent le levier de performance le plus important dans la conception d’architecture 4D, et également le plus simple à sur-appliquer.

Quoi indexer

Indexez tout champ utilisé comme clé étrangère d’une relation, tout champ fréquemment utilisé dans les critères de recherche d’une requête et tout champ utilisé pour le tri dans de grandes zones de liste. 4D prend en charge les index B-tree standards, les index de mots-clés pour la recherche de texte basée sur des mots et les index composites couvrant plusieurs champs.

Ce qu’il ne faut pas indexer

Chaque index ajoute des coûts d’écriture et de stockage. Indexer un champ booléen avec deux valeurs possibles est rarement utile. L’indexation d’un champ qui n’est lu que dans le cadre d’un affichage d’enregistrement complet ajoute une surcharge sans gain. Examinez les index une fois que l’application a de véritables modèles d’utilisation plutôt que de deviner à l’avance.

Stratégie de requête

Les requêtes ORDA (ds.Invoice.query("Status = :1"; "Open")) sont généralement préférables aux commandes QUERY classiques pour le nouveau code car elles renvoient des sélections d’entités qui peuvent être triées, filtrées et transmises entre les méthodes sans nouvelle requête. Pour les très grandes tables, restreindre la requête avec des critères indexés avant d’appliquer des filtres non indexés permet de conserver des temps de réponse prévisibles.

Connexes : Knack — Un générateur de base de données sans code destiné aux portails, aux annuaires et aux outils internes, avec une tarification forfaitaire au lieu de frais par utilisateur..

ORDA et l’architecture 4D moderne

ORDA (Object Relational Data Access) est la couche d’accès aux données orientée objet de 4D, introduite dans 4D v17. Il expose les tables en tant que classes de données et les enregistrements en tant qu’entités, donc une table nommée « Invoice » devient « ds.Invoice » et un champ nommé « TotalNet » devient « $invoice.TotalNet ».

Cela a une conséquence architecturale pour la conception de l’architecture 4d : les noms de tables et de champs font désormais partie de votre API publique. Renommer un champ interrompt le code d’une manière visible au moment de la compilation, mais une dénomination incohérente rend le code ORDA difficile à lire. Adopter une convention (noms de table singuliers, champs PascalCase, pas d’abréviations) s’avère immédiatement rentable.

ORDA prend également en charge les sélections d’entités côté client qui ne sont que partiellement chargées, ce qui modifie le profil de performances des écrans de liste. Une zone de liste liée à une sélection d’entités peut afficher des milliers de lignes sans charger chaque enregistrement, en supposant que la requête derrière elle est indexée.

Notre sélection : Claris FileMaker Pro — La plateforme de base de données relationnelle de longue date pour les équipes qui ont besoin d'applications personnalisées sur ordinateur, Web et mobile à partir d'un seul fichier..

Déploiement client-serveur, mono-utilisateur et Web

La topologie de déploiement façonne la conception de l’architecture 4d plus que ce à quoi de nombreux développeurs s’attendent.

Les applications mono-utilisateur exécutent le moteur de données et l’interface en un seul processus. Le verrouillage est trivial ; Le réglage des performances concerne principalement la vitesse du disque local.

Client-serveur sépare le 4D Server (moteur de données) du 4D Client (interface). Les enregistrements sont verrouillés sur le serveur et le coût aller-retour réseau de chaque requête devient important. Les architectures qui émettent de nombreuses petites requêtes par écran fonctionnent ici mal ; le regroupement des requêtes et l’utilisation de sélections d’entités réduisent les allers-retours.

Le déploiement Web et REST expose le même modèle de données via le serveur REST de 4D ou via des méthodes web compilées. La sécurité passe au premier plan : l’accès aux tables et aux champs doit être restreint par des rôles et des privilèges, et toute règle métier appliquée uniquement dans une méthode de formulaire n’est en réalité pas appliquée pour les clients Web.

Conventions de dénomination et documentation

Une dénomination cohérente n’est pas glamour mais décisive pour la conception d’une architecture 4D. Une convention réalisable pour 4D :

• Tables : Noms singuliers, PascalCase (« Client », « InvoiceLine »).
• Champs : PascalCase, sans préfixes de type (« InvoiceDate », pas « dInvDate »).
• Relations : nommées selon la table de destination (« Customer_Invoices »).
• Méthodes : verbe en premier (« CreateInvoice », « RecalculateTotals »).
• Classes : Nom en premier (« InvoiceService », « TaxCalculator »).

Documenter le schéma, même sous la forme d’un seul fichier Markdown répertoriant chaque table, son objectif et ses relations clés, facilite grandement l’intégration et les migrations futures. L’éditeur de structure de 4D affiche les relations graphiquement, mais il n’explique pas pourquoi une table existe.

Erreurs courantes de conception d’architecture 4D

Mettre la logique métier dans les méthodes de formulaire. Les méthodes de formulaire ne peuvent pas être appelées à partir de contextes Web ou de tâches planifiées, la logique qui y est piégée doit donc être dupliquée.

Utilisation de commandes classiques basées sur la sélection dans le nouveau code. Les sélections classiques sont liées aux processus et ne circulent pas bien entre les processus ; Les sélections d’entités ORDA sont plus flexibles.

** Oublier la table de jonction. ** Le stockage de plusieurs valeurs dans un seul champ de texte (ID séparés par des virgules) annule l’indexation et rend la création de rapports pénible.

Tout indexer. Les performances d’écriture se dégradent et les avantages sont rarement réalisés.

Ignorer les privilèges jusqu’au déploiement. Il est bien plus difficile de adapter un modèle de sécurité sur une application terminée que de le concevoir parallèlement au schéma.

Comment décider : une liste de contrôle pratique

Avant de créer votre conception d’architecture 4D, répondez à ces questions :

1. Combien d’utilisateurs simultanés et se connecteront-ils via un réseau LAN, WAN ou Web ?
2. Quelles entités ont une relation naturelle un-à-plusieurs et lesquelles ont besoin de tables de jonction ?
3. Quels champs apparaîtront dans les critères de recherche ou les ordres de tri sur les grandes tables ?
4. Quelles règles métier doivent être valables quel que soit le point d’entrée (formulaire, Web, importation) ?
5. Les données seront-elles un jour fusionnées avec un autre système, nécessitant des clés UUID ?
6. Qui maintiendra cela dans deux ans, et le nom aura-t-il un sens pour eux ?

Les réponses à ces six questions déterminent la plupart des décisions structurelles dans un projet 4D.

Lectures complémentaires

La documentation officielle de 4D sur Developer.4d.com couvre en détail ORDA, les classes, les privilèges et le déploiement. Pour connaître les principes fondamentaux de la modélisation relationnelle qui s’appliquent quelle que soit la plate-forme, consultez l’article Wikipédia sur la normalisation des bases de données. Pour le contexte plus large des plateformes de développement d’applications low-code et rapide, l’entrée Wikipédia sur les plateformes de développement low-code est un point de départ raisonnable. 4D SAS publie également des notes de version et des guides de migration qui décrivent quand ORDA, les classes et autres fonctionnalités de conception d’architecture 4d ont été introduites.

Questions fréquemment posées

Qu’est-ce que la conception d’architecture 4D ?

La conception d’une architecture 4D est le processus de planification de la structure d’une application 4D (4ème Dimension) : ses tables, ses champs, ses relations, ses index, sa couche de logique métier et sa couche de présentation. Il détermine les performances de l’application, la facilité avec laquelle elle peut être modifiée et le degré de sécurité avec lequel elle peut être déployée sur des clients de bureau, client-serveur ou Web.

L’architecture 4D est-elle la même que le 4D BIM ?

Non. 4D BIM ajoute le temps comme quatrième dimension à la modélisation des informations du bâtiment pour la planification des travaux. L’architecture 4D au sens logiciel fait référence à la conception d’applications sur la plateforme de base de données 4D. Les deux champs partagent une abréviation mais rien d’autre.

Dois-je utiliser ORDA ou les commandes 4D classiques ?

ORDA est la meilleure option pour les nouveaux développements. Il renvoie des sélections d’entités qui peuvent être transmises entre méthodes, triées et filtrées sans avoir besoin d’être à nouveau interrogées, et expose les tables et les champs en tant que propriétés d’objets lisibles. Les commandes classiques basées sur la sélection sont toujours utiles dans le code existant et dans certains cas particuliers.

Combien d’index doit avoir une table 4D ?

Il n’y a pas de nombre fixe. Indexez les clés étrangères, les champs utilisés dans les critères de recherche courants et les champs utilisés pour trier les grandes listes. Évitez d’indexer les champs à faible cardinalité, tels que les valeurs booléennes ou les champs d’état à deux ou trois valeurs, car le coût d’écriture dépasse généralement le bénéfice en lecture.

Quel type de clé primaire choisir dans 4D ?

Les clés longues à incrémentation automatique sont compactes et rapides, et conviennent aux applications sur site unique. Les clés de texte UUID sont plus grandes mais uniques au monde, ce qui est important lors de la fusion de données de plusieurs sites ou de l’intégration avec des systèmes externes. De nombreux projets utilisent une clé longint en interne ainsi qu’un champ de référence externe unique.

Puis-je changer le modèle de données 4D après le déploiement ?

Oui, mais avec précaution. L’ajout de tables, de champs et d’index est généralement simple. Changer les types de champs, renommer les champs utilisés par le code ORDA ou restructurer les relations sur une base de données en direct nécessite une migration planifiée, idéalement testée au préalable sur une copie des données de production.