Discussion :

[supertux54]

Bonjour,

Je suis en train de modéliser une gestion de parc matériels avec des spécifications propre à mon entreprise. Mon problème est que plusieurs tables possèdent des clés primaires composites qui conservent donc une information sur la table en relation

Par exemple :
CONSTRUCTEUR: (ID_FAB) ... -----> MODELE (ID_MOD,#ID_FAB) [Ici le id ne sont pas un nombre mais un TAG de 4 caractères]. (des constructeurs différents peuvent avoir des nom de modèles identiques).

Mon problème est la propagation de ID_FAB au niveau d'autres tables, car sur ce principe certaines tables ont des clés composites de 5 champs, qui ne me choque pas en soi, mais c'est plutôt lourd.
Je recherche donc des avis ou des conseils ou orienter mes choix. La propagation peut avoir des avantages au niveau des requêtes car les jointures peuvent êtres réduites du à la transitivité mais au détriment d'une "légèreté" d'écriture.

La performance "absolue" n'est pas à l'ordre du jour, et je pense que pas que des autoindex soient toujours une solution puisque des contraintes d'unicités peuvent être gérées directement sur les champs au besoin.

Merci de vos retour.

[fsmrel]

Bonsoir supertux54,

La propagation peut avoir des avantages au niveau des requêtes car les jointures peuvent être réduites du à la transitivité mais au détriment d'une "légèreté" d'écriture.

Le nombre de jointures peut être réduit, donc la performance des requêtes y trouver son compte. Pour avoir prototypé des dizaines de très grosses applications où l’on manipulait des tables dotées de clés multi-colonnes, je peux dire que ces applications s’en sont toujours bien portées. Du reste, rien ne vous empêche de prototyper et quantifier à votre tour. En tout cas, en ce qui concerne la légèreté d’écriture, on peut parfois inverser le propos...


Au sujet de ces clés multi-colonnes, voyez l’exemple 4 du paragraphe 1.7 : « Dénormalisation vs amélioration (optimisation) » de mon article sur la normalisation.
Voyez aussi le paragraphe « F. Identification relative versus identification absolue ».

En procédant ainsi, vous pouvez résoudre bien des contraintes de chemin (cf. « F.4. L'identification relative au service de l'intégrité des données », voyez encore ici ou là, entre autres...

Ici le id ne sont pas un nombre mais un TAG de 4 caractères

Hum...Codes significatifs ? S'il en est ainsi, méditez ce qu’a écrit Yves Tabourier il y a plus de 25 ans en termes merisiens (De l’autre côté de MERISE, page 80), et c’est une règle d’or encore malheureusement trop souvent méconnue :

« ... la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques.
L’expérience montre d’ailleurs que l’usage des “identifiants significatifs” (ou “codes significatifs”) a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d’autres objets... »

Et ce qu’a écrit Y. Tabourier, je l’ai souvent constaté, c'est-à-dire que j’ai vu des applications devant être réécrites car prises dans le béton avec ce genre d’affaire...

je pense que pas que des autoindex soient toujours une solution

Que sont ces choses-là ?

[supertux54]

Bonjour,

Merci d'avoir pris le temps de me répondre. Je vais me plonger rapidement dans vos liens et méditer sur la citation de M. Tabourier.

Citation Envoyé par supertux54
je pense que pas que des autoindex soient toujours une solution
Que sont ces choses-là ?

Des trucs issue de bien mauvais conseils avant de me documenter correctement sur les BDD , mais que je vois régulièrement fleurir.

[supertux54]

Un grand merci, j'ai trouvé les réponses à mes questions. Reste à digérer et à revoir une partie de mon travail (minime).

Bonne continuation.