[BD] Problème de modélisation

Problème de modélisation [BD] - Programmation

Marsh Posté le 24-07-2001 à 20:25:33    

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]

Reply

Marsh Posté le 24-07-2001 à 20:25:33   

Reply

Marsh Posté le 25-07-2001 à 08:26:08    

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.


---------------
di. / www.diredaredare.org - Ailes de la ville
Reply

Marsh Posté le 26-07-2001 à 13:34:19    

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.

Reply

Marsh Posté le 26-07-2001 à 13:48:08    

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


---------------
di. / www.diredaredare.org - Ailes de la ville
Reply

Marsh Posté le 26-07-2001 à 15:44:29    

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...:??:

Reply

Marsh Posté le 26-07-2001 à 16:30:39    

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.


---------------
di. / www.diredaredare.org - Ailes de la ville
Reply

Marsh Posté le 26-07-2001 à 17:29:47    

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]

Reply

Marsh Posté le 26-07-2001 à 17:43:26    

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]

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed