Discussion :

[whynot75]

bonjour à tous,
je resume mon soucis.
voila, si dans mon programme de gestion j'ai les tables

FACTURE (id_facture, id client, montantHT, date etc...)
lié à ma table CLIENT (par l'id client):
CLIENT (id_client, nom, prenom, adresse etc..)

donc les factures sont crées et enregistrées.
Si en cours d'année je crée et donne au client une facture 1. et ensuite l'adresse du clients change.
dans ce cas, dans mon programme de gestion les factures ne sont plus bonnes (car ma facture 1 générable sera avec le nouvelles adresse du client alors que le client aura la facture que je lui ai remis avant la modification de son adresse dans ma table client).

ma question:
pour avoir toujours les factures identiques à celles remises à mon client sur mon programme de gestion, est il preferable que j'ajoute dans ma table FACTURE le champ CLIENT.adresse qui sera une copie de CLIENT.adresse à l'instant ou je génére et donne la facture au client?

donc j'aurais FACTURE (id_facture, id client, montantHT, date, client_adresse etc...) ?

ou bien que j'ajoute un historique client en créant une table ADRESSE(id_client, date, coordonnées)
ce qui complique bien le developpement par rapport à si j'insere juste le champs CLIENT_adresse dans la table FACTURE.

merci pour vos reponses.

[developpeurP00]

Bonjour . Il faut séparer l'adresse de la table client.

avec ceci , tu dois associer une commande à la fois à la table 'adresse de facturation' et et la table 'client' .

si le client change d'adresse , ce n'est pas grave , l'id de l'ancienne adresse est toujours présent dans la commande (car cette adresse est toujours gardée dans ta base de données)

As tu fait comme ça ?

[whynot75]

bonjour utilisateur 38,
non je n'ai pas fait comme ca. ce que j'ai fait:
j'ai ajouté le champs FACTURE(adresse, cp, ville, TVA1, TVA3, TVA4, TVA5 etc...) à ma table FACTURE.

bref j'ai mis les infos d'adresse de facturation ainsi que les taux de la facture directement dans la table facture.

ainsi si le 5 taux de TVA changent (mon programme permet 5 taux de tva differents), les factures émises gardent les bon taux.
je sais que ce n'est pas correct niveau merise mais ca simplifie la programmation pour moi de ne pas avoir trop de tables.
qu'en pensez vous ?

En tout cas ca fonctionne bien meme si ca fait des infos redondantes

[escartefigue]

Bonjour,

La simplification de la programmation ne doit en aucun cas être un critère pour déroger aux règles de modélisation !
La structure de la base de données, c'est un peu comme les fondations d'une maison, si elle est mal conçue, alors vous le paierez cash par l'intégrité des données non assurée, les perfs dégradées, l'espace disque inutilement encombré et les traitements complexes pour contourner les problèmes.
Est ce qu'un cuisinier enlève la moitié des ingrédients de ses recettes sous prétexte que c'est trop compliqué ?

Si vous avez des difficultés avec les jointures, formez vous à SQL, les jointures sont très simples à mettre en œuvre avec un peu de pratique.
Voici un lien qui pourra vous aider si nécessaire : https://www.developpez.net/forums/d6...q-langage-sql/

[whynot75]

merci escartefigue,
effectivement je vais modifier et ajouter une table adresse_facturation.

mais si on s'en tient vraiment aux regles de modelisation, pour une petite appli réalisable rapidement et non soumise à modification par la suite, elle s'alourdit parfois beaucoup et complique la saisie par l'utilisateur (en gros pour chaque table je fais une fenetre d'ajout, modification et suppression à mon programme)

par exemple pour etre rigoureux il faudrait aussi ajouter la table Adresse_Client car l'adresse du client (du siege social par exemple) peut etre difference de l'adresse de facturation et aussi changer au cours du temps.

et dans ce cas il me semblerait plus simple d'ajouter la table EN_TETE (id_en_tete, adresse_client, adresse_Facturation). et le champs id_en_tete à ma table FACTURE
ce ne serait pas plus mal non ?

une facture serai lié à une EN_TETE par l' id_en_tete
et la table EN_TETE contiendrait les infos necessaires à l'en tete de la facture au moment de la création de celle-ci.

je parle bien pour une petite application, comme une application de facturation ou l'utilisateur ne saisirait que 200 factures au maximum par an, dans ce cas je ne pense pas que ca changerait grand chose niveau performance, espace disque etc..

[escartefigue]

mais si on s'en tient vraiment aux regles de modelisation, pour une petite appli réalisable rapidement et non soumise à modification par la suite, elle s'alourdit parfois beaucoup et complique la saisie par l'utilisateur (en gros pour chaque table je fais une fenetre d'ajout, modification et suppression à mon programme)

Toute application évolue un jour ou l'autre, si la modélisation est bien faite, l'évolution est aisée, et inversement.
Le nombre de tables ne pilote aucunement le nombre de fenêtres dans l'application.
Vous pouvez par exemple avoir une fenêtre de saisie de facture avec une partie entête reprenant les éléments du client et un corps avec autant de lignes que d'articles à facturer

par exemple pour etre rigoureux il faudrait aussi ajouter la table Adresse_Client car l'adresse du client (du siege social par exemple) peut etre difference de l'adresse de facturation et aussi changer au cours du temps.

Le mieux est de typer les adresses : une seule entité-type adresse chaque adresse possède un type, par exemple 0=par défaut, 1=de facturation, 2=de livraison, 3=de correspondance...
Vous pouvez créer un lien à date entre le client et l'adresse

et dans ce cas il me semblerait plus simple d'ajouter la table EN_TETE (id_en_tete, adresse_client, adresse_Facturation). et le champs id_en_tete à ma table FACTURE
ce ne serait pas plus mal non ?

Ce n'est pas une bonne idée, il ne faut jamais répéter les données, c'est une règle de base, et elle s’explique aisément : si certains clients sont livrés et facturés à la même adresse, alors une des deux adresses est redondante, si demain vous avez besoin d'une troisième adresse alors vous êtes contraint de modifier la table.
Utilisez ce que je vous propose plus haut.

je parle bien pour une petite application, comme une application de facturation ou l'utilisateur ne saisirait que 200 factures au maximum par an, dans ce cas je ne pense pas que ca changerait grand chose niveau performance, espace disque etc..

Les performances sont effectivement plus sensibles quand le volume d'informations est important.
Par contre quelque soit le volume dans la base de données, si les formes normales ne sont pas respectées, il y a un risque concernant l'intégrité des données, or, la première qualité d'une base de données est de garantir la fiabilité des données
Comme il n'est pas plus compliqué de bien faire que de mal faire, je dirai même que c'est plutôt l'inverse, autant s'habituer de suite aux bonnes pratiques, les maintenances inévitables à venir en seront plus aisées.

[whynot75]

Le mieux est de typer les adresses : une seule entité-type adresse chaque adresse possède un type, par exemple 0=par défaut, 1=de facturation, 2=de livraison, 3=de correspondance...
Vous pouvez créer un lien à date entre le client et l'adresse

oui effectivement, c'est ce point qui me prenait la tete (l'idée d'avoir une table adresse livraison, puis une table adresse facturation etc..)
en ayant une seule table adresse avec un type (0, 1, 2 ou 3), ca me va tres bien, merci beaucoup