Discussion :

[imadin]

bonjour

la question est dans l'intitulé
j'ai une table client et une table dossier
un client a un ou plusieurs dossier
le dossier a plusieurs statuts : en suspension , actif ou bien résilié

je dois faire dans mon application Java des statistiques sur le nombre de suspension d'un dossier donné ....etc

est qu'il est recommandé de faire un champ nb_suspension dans la table ou bien un petit programme PL/SQL qui fait le calcul à chaque changement du statut
au lieu de faire la mise à jour dans la table sur le champ nb_suspension ...etc



autre question //
j'ai une autre table facture , un dossier a une ou plusieurs factures ......
pour chaque facture il y a une date (champ date de facture )

dans l'application aussi je dois afficher dans chaque dossier la date de la première facture et la dernière facture , la même question, est que je fais 2 champs pour stocker la date de la première et la dernière facture dans la table dossier ou bien je les trouver à partir de la table facture avec SQL ou PL/SQL

je sais que tous les solutions sont justes mais je cherche la meilleure solution (performance ....etc)

avantages et inconvénients

merci

[CinePhil]

En principe, on ne stocke pas de données calculées.

Ce principe peut être remis en cause si les performances se dégradent mais après avoir bien normalisé sa BDD, l'avoir bien indexée et toutes autres opérations d'optimisation sur les tables, vues, requêtes... et même code de l'application utilisatrice. Car remettre en cause ce principe constitue une dénormalisation de la BDD.

Pour le premier besoin, les statistiques peuvent généralement être faites efficacement avec une requête SQL. Java prépare la requête et la soumet au SGBD qui renvoie la réponse.

Pour le second besoin, là aussi une simple requête SQL donne le résultat.

[imadin]

merci pour ta résponse , autre question , pour les clés est qu'il est recommandé de les regrouper dans une seule table pour minimiser le nombre de jointures entre les tables ??

[CinePhil]

Il ne faut pas avoir peur des jointures ; les SGBD sont particulièrement optimisés pour ça parce que c'est leur boulot, leur raison d'être : les relations entre les tables.

Il doit y avoir une clé primaire par table :
- Mono-colonne, le plus souvent un simple identifiant de type entier non nul non signé et auto-incrémenté, lorsque la table est issue d'une entité du MCD.
- Multi-colonnes, constituée des identifiants des entités participant à une association du MCD, lorsque la table est issue d'une association du MCD. Ces identifiants sont également clés étrangères dans la table.

Exemple...
Règle de gestion :
"Une personne peut participer à un projet et un projet peut voir participer plusieurs personnes."

MCD :
Personne -0,n----Participer----0,n- Projet

Tables :
Personne (prs_id, prs_nom, prs_prenom...)
Projet (prj_id, prj_nom...)
Participation (prt_id_personne, prt_id_projet)

Les clés primaires sont soulignées, les clés étrangères sont en italique.

Encore une fois, il faut d'abord normaliser au maximum puis n'envisager la dénormalisation que lorsque les performances se dégradent.

[imadin]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Il ne faut pas avoir peur des jointures ; les SGBD sont particulièrement optimisés pour ça parce que c'est leur boulot, leur raison d'être : les relations entre les tables.

mais lorsque le nombre de jointures s'augmente , le temps d'exécution s'augmente aussi , j'ai par exemple 4 tables et je dois stocker des données volumineuse sur ma BD , une table client oû chaque client a plusieurs dossiers et une table dossier oû chaque dossier a plusieurs factures , une table facture et autre table litige, pour chaque facture il est possible de faire des litiges
la solution la plus simple et la plus relationnelle est faire comme suit :
Client ( client_id , ......)
Dossier ( dos_id, client_id ......)
Facture ( fct_id , dos_id , ...)
Litige ( litige_id, fct_id, .....)

mais pourquoi on ne fait pas comme ceci :

client ( client_id , ...)
dossier ( dos_id , ....)
facture(fct_id , ....)
litige ( litige_id , ...)

et autre table Ref (red_id , client_id , dos_id , fct_id , litige_id )

la deuxième est mieux si je veux par exemple extraitre les informations du client qui a le litige numero X mais il est moins relationnelle comme ça non ?

[CinePhil]

Le premier schéma est le plus habituel.
Le deuxième est plus bizarre !
Il en existe un troisième qui consiste à faire une identification relative qui propage les clés primaires de table en table :
Client -0,n----Avoir----(1,1)- Dossier -0,n----Contenir----(1,1)- Facture -0,n----Entrainer----(1,1)- Litige

Les cardinalités entre parenthèses note l'identification relative. Au niveau des tables, ça donne ceci :
Client (client_id,...)
Dossier (client_id, dossier_id,...)
Facture (client_id, dossier_id, facture_id,...)
Litige (client_id, dossier_id, facture_id, litige_id,...)

Si tu cherches tous les litiges ou toutes les factures du client X, pas besoin de jointures !

[imadin]

hmm tu me conseilles d'utiliser le premier schéma donc

Client ( client_id , ......)
Dossier ( dos_id, client_id ......)
Facture ( fct_id , dos_id , ...)
Litige ( litige_id, fct_id, .....)



ou bien le deuxième qui propage les clés primaires de table en table

[CinePhil]

Oui.

[imadin]

ok , merci pour les réponses