---
title: Datasources
description: "## 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…"
url: "https://wiki.biboard.fr/wiki/bonnes-pratiques-datasources/"
updated: "2026-05-19"
category: Bonnes pratiques
---

# Datasources

## 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.