Discussion :

[djskyz]

Bonjour à tous,

Je suis devant un cas d'école et j'aimerai bien avoir votre avis.

Un cas typique de Gestion de factures Facture / LgFacture / Article.

Les méthodologie nous interdise de mettre des champs calculés dans les tables.

Donc si on considère un article qui a une fiche Prix, comment faite vous actuellement dans vos productions ?

Vous reportez les montants dans les lignes de factures ou vous rester coller au mcd en gérant une date de changement dans la fiche prix ?

La deuxieme solution me parait un peu difficile a maintenir si l'on gere un gros volumes de factures et que l'on ne peux pas se permettre d'archiver la base tout les ans.

Merci d'avance pour le partage de vos expériences sur le sujet.

[fsmrel]

La ligne de facture est porteuse de la vérité de ce que le client a payé :
Le montant de l’article doit figurer dans la ligne de facture (on est jamais à l’abri d’un update intempestif, dommageable pour la comptabilité de l'entreprise).

Quant aux méthodologies, c’est à vous de décider de les suivre quand vous estimez que dans telle et telle situations cela en vaut la peine. Sinon, si vous avez assez d’assurance et considérez comme légitime de ne pas suivre les méthodologues dans telle et telle autres situations, considérez qu’ils ne détiennent pas une vérité absolue, qu’ils sont sujets aux imprévus et que la pertinence votre jugement est à prendre en considération.


Précision :

Ceci concerne le niveau conceptuel. Au niveau logique, la théorie relationnelle prend le relais. Elle n’est aucunement concernée par des considérations relatives aux données calculées et autres. Les seules exigences de cette théorie :

Interdiction des tuples en double : en effet, le corps d’une relation (table en SQL) est un ensemble (au sens mathématique) dont les tuples (lignes en SQL) sont les éléments. A défaut, on aurait affaire à un sac (bag).

Chaque tuple contient exactement une valeur pour chacun de ses attributs (ceci caractérise ce qu’on appelle la première forme normale).

Les attributs de la relation (colonnes en SQL) n’ont pas à être ordonnés. En effet, ces attributs (<nom, type>) composent l’en-tête de la relation et cet en-tête est un ensemble.

Pour la même raison, les tuples composant le corps de la relation n’ont pas à être ordonnés.

Voilà pour la structure des données, les conditions permettant l’utilisation de l’algèbre relationnelle.

A cela vous pouvez ajouter les contraintes garantissant l’unicité des tuples grâce au mécanisme des clés candidates (clauses PRIMARY KEY et UNIQUE de SQL) et de l’intégrité référentielle. Sans oublier la possibilité que l’on puisse déclarer ses propres contraintes (assertions en SQL).