[BD] Problème de modélisation

Recherche :

Dernière réponse

Sujet : [BD] Problème de modélisation

AlphaT

instantdharma a écrit a écrit :

Solution 1 bis : après avoir archivé les 3 tables, tu supprimes les services & employés absents de services rendus pour diminue la taille (Optimisation simple, mais c'est le minimum).

Non car je dois tout conserver peut importe que l'employé soit supprimé ou non.

[edtdd]--Message édité par AlphaT--[/edtdd]

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

AlphaT

Non car je dois tout conserver peut importe que l'employé soit supprimé ou non.

[edtdd]--Message édité par AlphaT--[/edtdd]

AlphaT

instantdharma a écrit a écrit :

>> Omsey je suis pas d'accord avec toi. :eek2: Ta solution sent le gaz :D .
Si tu remplaces les suppressions physiques par des suppressions logiques, ça a 1 impact énorme sur tout le reste de l'appli : toute les autres requêtes relatives aux employés doivent être modifiées pour tenir compte du flag ; faut que ça soit documenté à mort parce que ce flag emboucanera l'appli tant que l'appli durera.
Ton idée n'améliore pas la structure de la base ; elle sert à contourner le problème posé mais les conséquences à long ou moyen terme ne sont pas prises en compte.

Exactement, tous les rapports sont produits en langage SQL. Cela me ferait chier de les alourdir avec une autre clause pour tenir compte du flag de suppression.

En ce qui concerne la table de services rendus (ID, Date, ID_Emp, ID_Client, ID_Service, NbHeures,Annule) ce sont des clé étrangères faisant référence aux tables de service (No, Nom, Description), table d'employé qui a fourni le service (ID_Emp, Nom_Emp, Adresse,Datenaiss...) a un client...

La solution 2 me semble moins compliquée pour moi et pour l'utilisateur-je dois donc copier le contenu de servrendu pendant l'année dans une autre table (avec la même structure) en nommant le fichier avec un suffixe pour les différencier

[edtdd]--Message édité par AlphaT--[/edtdd]

instantdharma

rufo a écrit :

Citation :

on erntre en "contradiction" avec un des grands principes de la BD : le pas dupliquer l'info...

C'est vrai, mais :
- la redondance est souvent utile.
- Dans le cas présent, on parle d'une archive, donc, dans un sens, c'est pas la même info... :sarcastic: faut voir à quoi sert l'archive et pourquoi on en a besoin.

rufo	c'est vrai que la solution 2 est assez plaisante. Moi, c'est ce que je ferai. cela dit, on erntre en "contradiction" avec un des grands principes de la BD : le pas dupliquer l'info...:??:

instantdharma

>> Omsey je suis pas d'accord avec toi. :eek2: Ta solution sent le gaz :D .
Si tu remplaces les suppressions physiques par des suppressions logiques, ça a 1 impact énorme sur tout le reste de l'appli : toute les autres requêtes relatives aux employés doivent être modifiées pour tenir compte du flag ; faut que ça soit documenté à mort parce que ce flag emboucanera l'appli tant que l'appli durera.
Ton idée n'améliore pas la structure de la base ; elle sert à contourner le problème posé mais les conséquences à long ou moyen terme ne sont pas prises en compte.

Omsey

Salut,
Moi ce que je te conseille c'est de mettre un flag dans ta table de personnes qui dit si elle est supprimée ou non. Comme ça ta contrainte d'integrité ne posera pas de problèmes puisque la personne existe toujours en base.
Lorsque tu selectionnera les personnes existantes il te suffira de spécifier la bonne valeur pour le flag de suppression.

instantdharma

Salut !
Dans ton post, il manque les clés primaires les références entre les tables, ce serait mieux. Si je comprends bien, ta table services rendus (sr) et l'archive (sra) ont 1 référence sur employé (emp).
Si tu supprimes un employé :pt1cable: , çà doit pas interagir sur le contenu de ton archive, pcq même si le mec est viré, le service rendu dans le passé le concernait, donc cette info doit être archivée (remarque : même problème avec les services).
Solution 1 : tu archives les 3 tables (un peu brutal, certes, mais efficace).
Solution 1 bis : après avoir archivé les 3 tables, tu supprimes les services & employés absents de services rendus pour diminue la taille (Optimisation simple, mais c'est le minimum).
Solution 2 : tu construis 1 table d'archive spécifique avec toutes les infos nécessaires, & tu la mets à jour par programme au moment de l'archivage.

AlphaT

J'ai une base de données en Delphi dans laquelle j'ai les tables suivantes :
-table de services
-table de clients (1 index pour rech. incrémentale sur le nom)
-table d'employés (1 index même que pour clients)
-table de services rendus (1 index: setrange sur la date)

Mon problème est que je dois copier la table de services rendus pour en faire une table d'archive. Cette table doit également être lue dans l'application (pour consulter les années antérieures à 2001).
Le problème est que si j'enlève un employé dans la base courante je ne peux plus faire des requêtes sur la table d'archive parce que le champ employé dans l'archive n'a plus de correspondance dans la table employé.

[edtdd]--Message édité par AlphaT--[/edtdd]