PC SOFT

PROFESSIONAL NEWSGROUPS
WINDEVWEBDEV and WINDEV Mobile

Home → WINDEV 2024 → Fusion de fichier dans une base de donnée
Fusion de fichier dans une base de donnée
Started by GB, Mar., 22 2024 3:20 PM - 12 replies
Registered member
328 messages
Popularité : +8 (10 votes)
Posted on March, 22 2024 - 3:20 PM
Je me pose une question sur l'architecture de ma base de donnée.

A ce jour j'ai un couple de fichier devis + ligne devis et un couple chantier + ligne chantier.

Les devis sont transférés en chantier (tout le devis, ou partiellement).

Devis et chantier possèdent quelques rubriques qui leur sont propres et une majorité communes entre eux.
Idem pour ligne devis et ligne chantier

Devis et chantier ont des fichiers liés identiques (exemple : historique devis ou chantier)
Chantier nécessite des fichiers annexes (suivi commande, suivi produit... etc) que ne nécessite pas un devis.

Je me pose donc la question de fusionner ou pas l'ensemble dans un couple document + ligne document (avec une rubrique de typage D ou C)

En terme de volume on avoisinerai 3000 à 5000 enregistrements pour document et 10 fois plus pour ligne document, par an ...

Au niveau métier, j'ai besoin de pouvoir accéder aux devis et chantier sur 10 ans afin d'avoir un suivi dans le temps. Ce suivi se fait via un client, donc il n'y quelques 10ene d'enregistrement a rechercher et afficher.


Quels avantages et inconvénients à garder 2 couples de fichier ou à fusionner ?

- en terme de programmation
- en terme d'accès aux données

Merci de vos réponses
Registered member
3,348 messages
Popularité : +93 (137 votes)
Posted on March, 22 2024 - 3:42 PM
Salut,
D'un point de vue comptable et juridique il ne faut pas fusionner.
Tu dois pouvoir garder le devis pour vérifier si il est respecté.
Le chantier tu dois pouvoir le suivre aussi, chaque chantier est un projet a part entière.
Registered member
328 messages
Popularité : +8 (10 votes)
Posted on March, 22 2024 - 3:51 PM
bonjour,

Je me suis peut etre mal exprimé !

Je parle en terme de fichiers...

aujourd'hui un devis = un enregistrement dans le fichier devis + des enregistrements dans le fichier ligne devis
un chantier idem.
Lors du transfert du devis en chantier, je copie de fichier a fichier

Si je fusionne en un fichier j'aurais toujours mes enregistrements devis et chantier distinctifs, mais dans un fichier au lieu de deux.
Ma réflexion se porte la dessus !
Registered member
113 messages
Popularité : +1 (1 vote)
Posted on March, 22 2024 - 4:10 PM
Bonjour,

Perso, autant que je le peux, j'ai toujours évité de dupliquer la même information.
Pour les informations spécifiques, des clés et des liaisons bien faites font le job.
Registered member
3,892 messages
Popularité : +227 (347 votes)
Posted on March, 22 2024 - 8:54 PM
Bonjour,
Plutôt que de faire une copie globale pourquoi ne pas utiliser un héritage ?
e.g.





Attention, les PK des tables héritées ne sont pas des IDAuto mais des numériques. Elles peuvent être créées avec un trigger après lors de la création de la pièce comptable.

Note :
NDX_TypePièce n'est utile que si les tables héritées sont mutuellement exclusives
--
Il y a peut être plus simple, mais, ça tourne
Message modified, March, 22 2024 - 9:19 PM
Registered member
328 messages
Popularité : +8 (10 votes)
Posted on March, 23 2024 - 8:08 AM
Bonjour

Je n ai pas tout compris...

Toutefois ça ressemble a l architecture de classe que je code en parallèle :

Une classe document
Une classe devis qui hérite de document
Une classe chantier qui hérite de document.

Si je comprends la basse aurait la même conception ?
Registered member
3,892 messages
Popularité : +227 (347 votes)
Posted on March, 23 2024 - 9:53 AM
GB a écrit :
Si je comprends la basse aurait la même conception ?

Oui.
Je ne vois d'ailleurs pas pourquoi il y aurait 2 modélisations différentes pour les mêmes données avec les mêmes règles de gestion.
Le MLD Merise et le diagramme des classe UML sont issus du même ERD. Ils ont obligatoirement une grande ressemblance.
--
Il y a peut être plus simple, mais, ça tourne
Message modified, March, 23 2024 - 10:06 AM
Registered member
328 messages
Popularité : +8 (10 votes)
Posted on March, 23 2024 - 11:12 AM
OK donc la clé de devis et chantier est en fait la clé de pièce comptable.

En regardant mieux les fichiers chantier et devis contiendront moins de 10 rubriques.

Ça ne vaut peut être pas le coup ?
Registered member
3,892 messages
Popularité : +227 (347 votes)
Posted on March, 23 2024 - 11:41 AM
GB a écrit :
OK donc la clé de devis et chantier est en fait la clé de pièce comptable.

On va dire qu'elles ont la même valeur. La PK (d'un devis ou d'un chantier) est aussi une clé étrangère qui pointe sur la pièce comptable (d'où mon préfixage PK_FK.)
En regardant mieux les fichiers chantier et devis contiendront moins de 10 rubriques.

Ça ne vaut peut être pas le coup ?

Moins de 10 attributs, c'est souvent le cas. Par ailleurs, si tu utilises un modèle objet à côté, le passage de l'un à l'autre sera fortement simplifié via un mappage.

--
Il y a peut être plus simple, mais, ça tourne
Registered member
328 messages
Popularité : +8 (10 votes)
Posted on March, 23 2024 - 2:21 PM
Oui en objet.

Document sera une classe abstraite avec des méthodes propres aux rubriques communes qui seront appelée via les classes filles
Registered member
328 messages
Popularité : +8 (10 votes)
Posted on March, 23 2024 - 6:50 PM
J'ai appliqué ta proposition en créant toutes les classes nécessaires. Et ça fonctionne ! il faut jouer avec les objets dynamiques et le polymorphisme

Concernant les fichiers :

on va donc avoir

Document (données communes) + lignes document (données communes)
Devis (données spécifiques au devis) + ligne devis (données spécifiques au devis)
Chantier (données spécifiques au chantier) + ligne chantier (données spécifiques au chantier)

Les classes reconstituent un devis ou un chantier en passant par les classes abstraites document et ligne document

N'est ce pas trop lourd ?

Je reviens sur ma question de base :

Un fichier document et ligne document + des classes Document (abstraite), Devis, et chantier ne permettrait pas plus de simplicité ? (la classe devis ne contiendrait pas toute les rubriques du fichier document)
C'est bancal ?
Registered member
3,892 messages
Popularité : +227 (347 votes)
Posted on March, 24 2024 - 12:46 AM
A priori, comme beaucoup malheureusement, tu a zappé la partie traitement de ton analyse (que ce soit le MCT-MOT ou le use case-Etat transition.)
Tu te serais aperçus que les 3 entités (chantier, document et devis) ou les attributs associés n'entrent pas dans les même traitements (e.g le chef de chantier importe peu dans la création du devis.) Si l'on a 3 "groupes de données" différents, on a 3 entités.

--
Il y a peut être plus simple, mais, ça tourne
Registered member
328 messages
Popularité : +8 (10 votes)
Posted on March, 24 2024 - 8:44 AM
J y passe du temps sur l analyse ... c'est plus l expérience qui me manque sur les bonne pratiques. Car dans les faits cela fonctionne. Je cherche à optimiser pour être efficace à long terme