Discussion :

[Li0303]

Bonjour,

Nous développons actuellement un logiciel ERP pour lequel la base de données et toutes les opérations standards sont déjà terminées et validées mais pour lequel il y a encore un gros travail à effectuer au niveau design (plutôt la partie "Vue" d'un MVVM).

Ce logiciel sera basé sur des fonctionnalités "standards" qui ne sont donc pas spécifiquement réalisés pour des métiers particuliers (bien que la cible soit plutôt l'industrie). Nous envisageons également la possibilité de créer des "thèmes" proposant des modules plus spécifiques à certains types de métier.

Néanmoins, puisque dans un même secteur, les processus de travail des entreprises et leurs besoins peuvent fortement varier; nous souhaitons pouvoir permettre de personnaliser l'application et la rendre au maximum flexible sans avoir à effectuer de modifications dans le code. Ceci aurait pur but de donner de la flexibilité aux consultants/chefs de projets chargés des implémentations de l'ERP sans avoir à passer par notre équipe de développement pour des modifications drastiques du code.

Ce que nous aimerions mettre en place :

- Les listes étant basée sur des requêtes SQL, nous voudrions par exemple pouvoir permettre via des requêtes SQL qui seraient introduites dans l'application, de créer des filtres ou des affichages personnalisés. (via un module de configuration, par exemple)
- Donner la possibilité d'ajouter des champs dans la base SQL qui ne seraient pas standards mais bien spécifiques à chaque client acquérant la solution. (Exemple, dans une table "PRODUCTS" qui reprend les articles, un client souhaite ajouter un champ "couleur de fond")
- Donner la possibilité aux utilisateurs de modifier eux-mêmes certains contextes d'écrans (exemple les colonnes affichées dans les listes, voire afficher/cacher un champ dans un écran ou, mieux, la possibilité d'afficher un champ de la DB créé spécifiquement pour le client)
- Donner la possibilité d'introduire (dans un module de configuration, par exemple) des requêtes SQL permettant d'effectuer des traitements supplémentaires que les traitements "standards" (par exemple : à l'enregistrement d'une facture le client souhaite que le timestamp soit injecter dans un champ "remarque")

Ces différents exemples sont essentiellement (sauf pour la partie "contexte d'écrans") basés sur du SQL, et permettrait d'avoir une couche "client" totalement indépendante du coeur du logiciel. (On peut éventuellement inclure ces fonctions dans des DLL qui seraient chargées au démarrage du logiciel et garder cela "interne" sans que ça ne soit éditable directement par le client; le but étant simplement d'avoir une couche client personnalisable)
...

Je sais que ce genre de possibilités de personnalisations existent sur certains ERPs et c'est selon moi un outil non négligeable permettant d'augmenter sensiblement la flexibilité d'un logiciel sans avoir à devoir systématiquement passer par des modifications dans le code, des recompilations, etc... (et ce qui obligerait également à maintenir des versions différentes du logiciel chez les majorité des clients)

Toutes les remarques ou idées sont les bienvenues

[WDKyle]

Bonsoir,

Je travail sur un projet qui ou la base de données est structurée pour que tout soit "dynamique". On considèrent les enregistrements comme des objets.

Je vous fait la version light, on a 4 tables principales :

- Une table contenant les instances d'objet.
- Une table décrivant le type de ces instances.
- Une table décrivant des attributs pouvant être liés à ces types.
- Une table contenant les valeurs de ces attributs pour chaque instances.

Et donc, en gros les rubriques de tables se transforment en attributs et la table contenant les valeurs n'a pas x rubriques inutiles mais un enregistrement par attribut.

C'est un peu déroutant au départ mais au moins cela fonctionne pour la majorité des types de logiciels car vraiment flexible et dynamique au final.

[Li0303]

Je n'avais pas pensé à ce type de possibilité mais c'est effectivement quelque chose qui pourrait s'adapter à mes besoins!

[François DORIN]

- Donner la possibilité d'ajouter des champs dans la base SQL qui ne seraient pas standards mais bien spécifiques à chaque client acquérant la solution. (Exemple, dans une table "PRODUCTS" qui reprend les articles, un client souhaite ajouter un champ "couleur de fond")

La plupart des SGBD supporte le XML et/ou le JSON comme type pour les données, et avec les outils nécessaires pour le requêtage. Rajouter une colonne de ce type permettrait donc de faire cela facilement.

- Donner la possibilité aux utilisateurs de modifier eux-mêmes certains contextes d'écrans (exemple les colonnes affichées dans les listes, voire afficher/cacher un champ dans un écran ou, mieux, la possibilité d'afficher un champ de la DB créé spécifiquement pour le client)

Il s'agit de sauvegarder des configurations des utilisateurs. La encore, un petit XML fait souvent bien l'affaire !

- Donner la possibilité d'introduire (dans un module de configuration, par exemple) des requêtes SQL permettant d'effectuer des traitements supplémentaires que les traitements "standards" (par exemple : à l'enregistrement d'une facture le client souhaite que le timestamp soit injecter dans un champ "remarque")

Plusieurs possibilités. La première est d'utiliser des triggers AFTER (mais ça peut être chiant s'il faut empiler les actions). La seconde est de créer des procédures stockées "hook", qui ne font rien dans la version de base de votre application, mais qui peuvent être éditées différemment pour chaque client. Il faut juste s'assurer que la procédure stockée est appelée lorsque l'événement en question à lieu (par exemple, lors de la modification d'une facture).

Je travail sur un projet qui ou la base de données est structurée pour que tout soit "dynamique". On considèrent les enregistrements comme des objets.

Je vous fait la version light, on a 4 tables principales :

- Une table contenant les instances d'objet.
- Une table décrivant le type de ces instances.
- Une table décrivant des attributs pouvant être liés à ces types.
- Une table contenant les valeurs de ces attributs pour chaque instances.

Je ne connais pas l'application donc je ne peux pas dire si cet usage est correct ou non dans votre cas précis, mais la solution que vous décrivez, même si elle est fonctionnellement correcte, est loin de convenir à tous les cas. De l'incidence sur la performance des requêtes à la difficulté de les écrire en passant par la destructuration complète de vos données, l'impact est loin d'être négligeable, aussi bien à l'exécution que durant les développements.

Il ne faut pas oublier que les SGBD sont, par définition, relationnelles et donc, pour être efficace, ont besoin de tables (n'oublions pas que relation = table dans le sens mathématique du terme). En enlevant cela, vous mettez au placard tous les outils proposés pour assurer la cohérence des données et les performances lors du requétage (clé primaire, clé étrangère, contrainte d'unicité, champ non nul, trigger, etc.).

Bref, dans un cas comme celui-ci, il est tout à fait pertinent de se poser la question de savoir si du NoSQL ne serait pas plus adapté.

[Li0303]

Le XML est une très bonne idée pour les contextes, merci.

Pour la partie "ajout de champs spécifiques", je ne suis par contre pas certain de la manière de pouvoir gérer cela.

Exemple, un client (XXX) aurait besoin de rajouter un champ "SPEC_TECHNIQUES" à la table de détails des commandes d'achats. (Appelée, par exemple, "CMDACHD"). L'objectif serait de permettre à la personne chargée de l'implémentation d'ajouter un champ XXX_SPEC_TECHNIQUES (nous partons de la règle que les champs "clients" doivent être précédés d'un préfixe clair afin d'éviter des conflits lors de mises à jour futures de la solution dans lesquels nous rajouterions des champs standards).

Nous aurions donc besoin de pouvoir afficher ce champ spécifique dans la grid d'encodage des détails de commandes d'achats; sans avoir a rentrer dans le code, et de recompiler, pour qu'il soit disponible.


Pour les exécutions de requêtes "spécifiques", j'avais également envisagé l'utilisation du trigger "AFTER" mais pour l'avoir fait dans un ERP existant que je m'implémentais, je trouvais que cela finissait par ralentir l'application... L'idée des procédures stockées me plait bien!

[François DORIN]

Pour la partie "ajout de champs spécifiques", je ne suis par contre pas certain de la manière de pouvoir gérer cela.

Exemple, un client (XXX) aurait besoin de rajouter un champ "SPEC_TECHNIQUES" à la table de détails des commandes d'achats. (Appelée, par exemple, "CMDACHD"). L'objectif serait de permettre à la personne chargée de l'implémentation d'ajouter un champ XXX_SPEC_TECHNIQUES (nous partons de la règle que les champs "clients" doivent être précédés d'un préfixe clair afin d'éviter des conflits lors de mises à jour futures de la solution dans lesquels nous rajouterions des champs standards).

Nous aurions donc besoin de pouvoir afficher ce champ spécifique dans la grid d'encodage des détails de commandes d'achats; sans avoir a rentrer dans le code, et de recompiler, pour qu'il soit disponible.

Qu'est-ce qui est bloquant exactement ?
Voici un exemple simpliste :

Code XML :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
<ExtraColumns>
   <Column Name="SPEC_TECHNIQUES" Value="..." />
</ExtraColumns>

On peut même y rajouter des informations de typage si nécessaire.

Pour les exécutions de requêtes "spécifiques", j'avais également envisagé l'utilisation du trigger "AFTER" mais pour l'avoir fait dans un ERP existant que je m'implémentais, je trouvais que cela finissait par ralentir l'application... L'idée des procédures stockées me plait bien!

Les performances varient d'un SGBD a un autre, mais par exemple, pour SQL Server, les triggers sont loin d'être les objets les plus performants. En fait, je crois même que ce sont les pires d'un point de vue perf ! Donc cela ne m'étonne guère...

[WDKyle]

C'est surement plus propre d'avoir des tables pour chaque modules. Mais en laissant la possibilité au client de modifier les structures de celles-ci, bonjour le foutoir pour mettre à jour la structure de la base si besoin, parce-que pas une seule base n'aura la même structure, il faudra gérer pas mal de cas...

A la rigueur, peut-être en ayant une table PRODUCTS de base qui n’évolue que par le développement. Et une table auxiliaire PRODUCTS_AUX pour gérer les besoins spécifiques des clients.

[Li0303]

C'est surement plus propre d'avoir des tables pour chaque modules. Mais en laissant la possibilité au client de modifier les structures de celles-ci, bonjour le foutoir pour mettre à jour la structure de la base si besoin, parce-que pas une seule base n'aura la même structure, il faudra gérer pas mal de cas...

A la rigueur, peut-être en ayant une table PRODUCTS de base qui n’évolue que par le développement. Et une table auxiliaire PRODUCTS_AUX pour gérer les besoins spécifiques des clients.

Le but c'est d'avoir une base de données "référence" qui contient uniquement les champs standards du logiciel (ceux qui sont donc nécessaires pour que l'exécutable "standard" tourne par défaut) qui, via un utilitaire tiers, permettent de faire une mise à jour des DBs clients lorsqu'une nouvelle version du logiciel est disponible. Le fonctionnement est simple : on fait un ajout des nouveaux champs qui ne se trouvent pas encore dans la DB. On ne supprime jamais aucun champ (même si pour une raison X ou Y un champ standard devenait obsolète, on le maintient dans la DB). Ca permet donc aux clients d'avoir des champs "spécifiques" (avec préfixe pour éviter qu'ils choisissent un nom que nous pourrions choisir pour une future version standard de l'ERP) ...

Ce qu'il faut, c'est qu'on puisse leur laisser la possibilité d'ajouter ces champs spécifiques dans certains écrans ou listes et c'est pourquoi il faudrait qu'on puisse stocker les affichages (autant les listes que les affichages "fiches" des différents modules) dans une table de configuration "user" ...