Discussion :

[fsmrel]

Bonsoir sudtek,


D’une manière générale, pour une bonne performance des requêtes (durée des requêtes < seuil psychologique avant que l’utilisateur ne balance son écran par la fenêtre), on met en oeuvre des index ad-hoc.

Les SGBD SQL exigent soviétiquement que la clé primaire d’une table soit dotée d’un index — dit index primaire — avec la contrainte supplémentaire dans le cas de MySQL que cet index primaire soit nécessairement cluster, et la table MACU n’y échappe pas (à comparer par exemple avec DB2 qui n’impose pas cette contrainte parfaitement stupide).

Peu importe, supposons que l’on définisse ainsi l’index primaire de la table MACU :

(idUE, idModule, idCategorie, idAnneUniversitaire)

Pour répondre à la question :

Pour l'année universitaire 2013 quelle sont les catégories ?

Si cette question est récurrente, on pourra définir un index supplémentaire (heureusement on n’est pas limité dans le nombre d’index !), ainsi composé :

(idAnneUniversitaire, idCategorie)

Le but de la manœuvre étant d’opérer en mode « index only », c'est-à-dire que toutes les données parties prenantes dans la requête soient directement récupérées dans l’index, sans que le SGBD ait besoin de plonger en plus dans la table MACU : s’il fallait aussi afficher les UE et les modules, on aurait intérêt à enrichir ainsi l’index :

(idAnneUniversitaire, idCategorie, idUE, idModule)

Ou peut-être ainsi :

(idAnneUniversitaire, idUE, idModule, idCategorie)

Tout dépend en l’occurrence de la façon dont vous souhaitez présenter les résultats.

N’oubliez pas que, si le nombre d’index n’est pas limité (au moins dans le cas de mon SGBD, à savoir DB2), plus il y a d’index pour une table, plus les mises à jour sont gourmandes.

Autre chose : en général il faut harmoniser l’organisation des clés des index primaires des tables en relation : par exemple il serait maladroit que pour la table MACU on ait l’organisation suivante

(idUE, idModule, idCategorie, idAnneUniversitaire)

Et pour la table EMACU (permutation de idUE et IdModule) :

(idModule, idUE, idCategorie, idAnneUniversitaire, idEleve)

Mais il n’y a pas de secret, en cas de doute sur les choix qu’on est en train de faire (essentiellement en ce qui concerne l’index cluster), on bâtit un prototype de performances et on décortique les résultats fournis par l’instruction EXPLAIN. Il est sûr qu’on peut avoir des choix à faire en fonction des requêtes les plus fréquentes : est-il mieux que l’index primaire de la table EMACU soit le celui-ci :

(idUE, idModule, idCategorie, idAnneUniversitaire, idEleve)

Ou celui-là :

(idEleve, idUE, idModule, idCategorie, idAnneUniversitaire)

La réponse dépend notamment de la structure des requêtes (dont les clauses ORDER BY, HAVING...) et de leur fréquence, d’où la nécessité au besoin de prototyper les performances.

[david1992]

svp quelqu'un peut me donné le MCDde la gestion des vente de pieces détaches d'automobile merci.
La Société VENPIECE fabrique et commercialise des pièces détachées pour automobiles qu'elle
vend à des garagistes, des grossistes, des constructeurs automobiles.

- A l'arrivée d'une commande d'un client, le Service Commercial enregistre à partir d'un terminal la
commande avec un numéro d'arrivée et la date d'arrivée.
- Le magasinier dispose d'un terminal. Durant la journée, il consulte la base de données pour
visualiser la liste de commandes à livrer. En fonction de la quantité en stock d'un produit
commandé, il enregistre la quantité réelle pouvant être livrée. Il édite un bon de livraison qui
servira à préparer le(s) colis.
- A partir du bon de livraison édité, le service préparation prépare le(s) colis, note sur le bon : le
poids, le nombre de colis, le nom du préparateur et rectifie la quantité livrée s'il a constaté une
anomalie dans le stock.
- Quand la préparation est terminée, le magasinier enregistre le poids, le nombre de colis, rectifie
la quantité livrée si nécessaire. Il édite le bon de livraison définitif à joindre au colis.
- En fin de journée, le Service Commercial lance la facturation des commandes préparées par le
magasinier. Il édite 2 exemplaires qu'il transmet au magasinier. Le magasinier joint les
exemplaires de facture aux colis; ils sont alors prêts à être expédiés.
- Chaque fin de journée, le magasinier édite la liste des produits en rupture de stock et à
réapprovisionner; il l'adresse au Service Approvisionnement.
- Chaque fin de mois, le Service Commercial édite le relevé des factures du mois de chaque client
et le lui adresse. Le client est tenu de régler le total des factures pour la date d'échéance en une
ou plusieurs fois au Service Comptabilité.
- En fin de journée, le magasinier enregistre les produits livrés; cette opération provoque la mise à
jour des quantités en stock. Il visualise ensuite les commandes incomplètement livrées par ordre
chronologique d'arrivée; il peut alors éditer de nouveaux bons de livraisons servant à la
préparation des colis.
- Le Service Comptabilité enregistre les règlements dès leur arrivée sur un terminal et met à jour
les comptes des clients. Si le relevé n'est pas payé 30 jours après la date d'échéance, on
déclenche une relance.
- Chaque semaine, on édite les relances des relevés non réglés dans le délai de 30 jours.
- A tout moment, le Service Commercial doit pouvoir répondre à une demande de renseignements
sur l'expédition d'une commande.
- Le Service Comptabilité souhaite avoir la possibilité d'imprimer l'état d'un compte client (relevé de
factures, règlements qui s'y rapportent) à la demande.