Définition des Datasources #

Une Datasource doit répondre à un besoin fonctionnel clair et identifiable.
Évitez les Datasources « fourre-tout » contenant des champs inutilisés ou destinés à plusieurs usages différents.

Quelques recommandations :

• Une Datasource = un objectif métier principal.
• Limiter le nombre de colonnes au strict nécessaire.
• Préférer plusieurs Datasources spécialisées plutôt qu’une unique Datasource complexe et difficile à maintenir.
• Documenter les champs complexes ou les traitements particuliers.

Nommage des Datasources #

Le nom d’une Datasource doit permettre de comprendre immédiatement son usage.

Recommandations #

• Utiliser un nom explicite et lisible.
• Éviter les abréviations techniques difficiles à comprendre.
• Conserver une convention homogène dans tout le projet.

Exemples #

Bonnes pratiques #

• DS_VentesMensuelles
• DS_CommandesClients
• DS_StockEntrepot

À éviter #

• Test
• Datasource1
• ReqSQLFinal
• TMP2

Plusieurs Datasources basées sur une même requête #

Il peut être pertinent de créer plusieurs Datasources à partir d’une même requête SQL afin de répondre à des usages différents.

Bonnes pratiques #

• Adapter le nom de chaque Datasource à son usage réel.
• Ne conserver que les champs utiles dans chaque Datasource.
• Éviter de dupliquer inutilement des champs calculés complexes.
• Centraliser la logique SQL principale lorsque cela est possible.

Exemple #

Une requête SQL commune peut alimenter :

• DS_VentesSynthese
• DS_VentesDetail
• DS_VentesExportComptable

Chaque Datasource répond alors à un besoin spécifique tout en conservant une base commune.

Champs calculés #

Les champs calculés doivent rester simples, lisibles et maintenables.

Nommage des champs calculés #

Le nom doit refléter clairement le résultat calculé.

Bonnes pratiques #

• CA_HT
• MontantTVA
• MargePourcentage
• DateLivraisonPrevue

À éviter #

• Calc1
• ResultFinal
• ChampTmp
• X1

Ordre des champs calculés #

Lorsqu’un champ calculé utilise un autre champ calculé, l’ordre de création devient important.

Recommandations #

• Créer d’abord les calculs de base.
• Créer ensuite les calculs dépendants.
• Regrouper les champs liés logiquement.
• Éviter les dépendances trop nombreuses entre champs calculés.

Exemple #

Ordre recommandé #

1. PrixHT
2. MontantTVA
3. PrixTTC

Le champ PrixTTC peut ainsi réutiliser les calculs précédents.

À éviter #

Créer PrixTTC avant MontantTVA si celui-ci est utilisé dans la formule.

Lisibilité des calculs #

Même dans un champ calculé simple, la lisibilité reste importante.

Recommandations #

• Éviter les formules trop longues.
• Découper les calculs complexes en plusieurs champs intermédiaires.
• Utiliser des noms explicites.
• Supprimer les champs intermédiaires inutilisés.

Maintenance et évolutivité #

Une Datasource bien conçue facilite les évolutions futures.

Conseils #

• Anticiper les futurs besoins sans surcharger inutilement la Datasource.
• Supprimer les anciens champs non utilisés.
• Vérifier régulièrement les dépendances entre champs calculés.
• Uniformiser les conventions de nommage entre les projets.

Performance #

Une Datasource trop complexe peut dégrader les performances.

Recommandations #

• Limiter les calculs inutiles.
• Préférer les traitements SQL lorsque cela est pertinent.
• Éviter les champs calculés redondants.
• Réutiliser les Datasources existantes lorsque cela est possible.