Discussion :

[MickSou]

Bonjour à tous,
Je suis en train de modéliser une base de données et je me pose (soudainement) une question existentielle:

Prenons l'exemple d'un commande et de lignes de commandes associées.

Je souhaitais associer une clé primaire 'id' (générée par un générateur à chacune de ces tables) et lier les deux tables par une clé étrangère placée dans la tables lignes et comportant l'id de la commande associée.

commandes (id)
lignes(id, id_commande)

Or je me demande si pour des raisons de performance il ne faudrait pas que je reprenne tout et que je crée une clé primaire double dans la table ligne composée de l'id de la commande + le numéro de la ligne. Auquel cas je ne fonctionne plus qu'avec un seul générateur. qu'en pensez-vous?

commandes (id)
lignes(id_commande, num_ligne)


Merci de vos conseils.
Michael

[Ph. B.]

Bonjour,

Prenons l'exemple d'un commande et de lignes de commandes associées.

Je souhaitais associer une clé primaire 'id' (générée par un générateur à chacune de ces tables) et lier les deux tables par une clé étrangère placée dans la tables lignes et comportant l'id de la commande associée.

commandes (id)
lignes(id, id_commande)

Cette modélisation là me va...
Une clé primaire, une clé étrangère, chacune étant la plus compacte possible.
Rappelez vous qu'un SGBDR génère un index derrière chaque clé, et que tout index a un cout (stockage, parcours).

Or je me demande si pour des raisons de performance il ne faudrait pas que je reprenne tout et que je crée une clé primaire double dans la table ligne composée de l'id de la commande + le numéro de la ligne. Auquel cas je ne fonctionne plus qu'avec un seul générateur. qu'en pensez-vous?

commandes (id)
lignes(id_commande, num_ligne)

En quoi cela va être plus performant ?
En rien, si j'en crois ce que j'ai dit précédemment. En outre, vous devrez gérer num_ligne vous même, donc rajouter quelque part du code pour contrôler et mettre à jour cette information (dans des déclencheurs, dans des traitements d'exceptions ou autres).
Par contre, vous pouvez toujours générer à la volée un num_ligne pour les éditions ou autres affichages...

Un peu de lecture pour finir sur le sujet des clés.

[SergioMaster]

Réponse de Normand :
Contrairement a Philippe je suis plus dubitatif , d'un pur point de vue modélisation effectivement je penche sur la première . D'un point de vue pratique par contre je penche sur la deuxième .



En fait , dans ma BDD cas j'ai plusieurs 'Carnet de commandes',répartis en Saisons (hé oui , même pas par année , vive la mode ) j'ai donc utilisé la technique citée de SQLPro (la table de Clés) pour les entêtes de Commandes
et pour les lignes la deuxième solution , un numéro de ligne (tant pis s'il y a des trous ) une commande n'étant saisie que par un seul intervenant)
Cependant pour des raisons de maintenance , j'ai quand même gardé mon générateur pour chacune de mes tables (en index secondaire plutôt que primaire) "Ceinture et bretelles" dira t'on a quoi je répondrai maintenance prévisible .

Une clé primaire, une clé étrangère, chacune étant la plus compacte possible.
Rappelez vous qu'un SGBDR génère un index derrière chaque clé, et que tout index a un cout (stockage, parcours).

Si au "siècle" dernier l'on était fort économe , ce temps semble (a mon grand dam) fortement révolu . De toute façon , ne serait-ce que pour optimiser les requêtes des clés "secondaires" seront certainement utiles .

-l'utilisateur recherchera la commande 2013H-156 pas la numéro (id) 71521445

pour ce qui est du N° de Ligne , en avoir un permet d'être sur que la commande sortira dans l'ordre voulu par l'utilisateur . Bien que j'ai toujours refusé la possibilité de changer l'ordre des lignes une fois saisie a mes utilisateurs , elle reste possible (peu demandée, mais reviens au fil du temps)
cette possibilité serait bloquée dans le cas d'une id auto-générée a la volée

[Ph. B.]

En fait , dans ma BDD cas j'ai plusieurs 'Carnet de commandes',répartis en Saisons (hé oui , même pas par année , vive la mode ) j'ai donc utilisé la technique citée de SQLPro (la table de Clés) pour les entêtes de Commandes
et pour les lignes la deuxième solution , un numéro de ligne (tant pis s'il y a des trous ) une commande n'étant saisie que par un seul intervenant)
Cependant pour des raisons de maintenance , j'ai quand même gardé mon générateur pour chacune de mes tables (en index secondaire plutôt que primaire) "Ceinture et bretelles" dira t'on a quoi je répondrai maintenance prévisible .

On peut avoir une colonne n° de ligne avec ce que je préconise, dans la table ou générée à la volée (cf. ci-après).

"Ceinture et bretelles" (qui sous-entend que la base peut être dans un état incohérent ?), par suite d'une conception de la base approximative ou une "podo-programmation" de l'application ?

Si au "siècle" dernier l'on était fort économe , ce temps semble (a mon grand dam) fortement révolu .

Je suis d'accord, mais ainsi, on voit mis en œuvre des clés primaires composées, à base de char, qui doivent se retrouver ultérieurement dans des clés étrangères, etc, etc.

De toute façon , ne serait-ce que pour optimiser les requêtes des clés "secondaires" seront certainement utiles .

-l'utilisateur recherchera la commande 2013H-156 pas la numéro (id) 71521445

Ma clé primaire n'empêche pas d'avoir une colonne comme décrite pour laquelle on aura une contrainte d'unicité, et un index associé, car c'est l'index qui va permettre d'optimiser le temps de réponse de la requête (le terme clé secondaire me parait inapproprié)...
(je sais, j'intégrise, mais bon... )

pour ce qui est du N° de Ligne , en avoir un permet d'être sur que la commande sortira dans l'ordre voulu par l'utilisateur . Bien que j'ai toujours refusé la possibilité de changer l'ordre des lignes une fois saisie a mes utilisateurs , elle reste possible (peu demandée, mais reviens au fil du temps)
cette possibilité serait bloquée dans le cas d'une id auto-générée a la volée

Non, si cet ordre dépend de l'utilisateur, elle peut être placée dans un ensemble de données via une colonne dédiée initialement auto générée mais modifiable ultérieurement par l'utilisateur.

[SergioMaster]

"Ceinture et bretelles" (qui sous-entend que la base peut être dans un état incohérent ?), par suite d'une conception de la base approximative ou une "podo-programmation" de l'application ?

non , j'ai juste eu affaire a un processeur en sur-chauffe , provoquant des pannes totalement aléatoires , depuis j'essaie de prévoir

Pour le reste , en fait , on dit pratiquement la même chose !

[MickSou]

Merci pour vos avis et conseils.
je suis effectivement habitué à n'utiliser qu'un id autogénéré et ajouter les colonnes plus significatives après (N° de commande, N° de réceptions, etc...)
Le doute m'est apparu en essayant de modéliser avec MySQLWorkbench (une bas de donnée firebird oui oui ;-) et que lorsque je voulais insérer des "Identifying Relationships"entre deux tables (excusez moi mais je ne trouve pas le terme en français) il insérait forcément la clé primaire de la table maitre pour l'insérer en tant que clé primaire de la tables dépendante.

Ma technique de clé basé sur une identifiant unique autogénéré m'oblige donc à ne créer (selon MySQL Workbench) à ne créer que des relations "non-identifying" ce qui d'un pint de vue dus ens n'est pas pertinent. D'un point de vue logique je coriq qu'une ligne de commande est forcément reliée à une commande et n'a pas d'existence en dehors de cette commande).

Encore un avis?
Merci ;-)

[comico]

Bonjour

Oui encore un avis.
Un jour ou l'autre on se retrouve en web (où l'on passe des paramètres pour trouver ce que l'on cherche) et là on remercie celui qui a choisi un identifiant unique et non une clé composée !

[e-ric]

Or je me demande si pour des raisons de performance il ne faudrait pas que je reprenne tout et que je crée une clé primaire double dans la table ligne composée de l'id de la commande + le numéro de la ligne. Auquel cas je ne fonctionne plus qu'avec un seul générateur. qu'en pensez-vous?

Perso, je pense que la première approche n'est pas mal, elle vaut bien la seconde. Pour ce qui des générateurs, sachant qu'avec FB on a droit à des entiers 64 bits, rien ne t'interdit d'utiliser un seul générateur pour toutes tes tables sauf si la clé doit être nécessairement séquentielle pour une table donnée.

Utiliser un seul générateur est logique dans le sens où on obtient un identifiant universel dans la base de données indépendant de l'objet représenté. C'est un choix de conception qui peut amener des simplifications dans le code de l'application, en écrivant du code générique pour tous les objets de ta base. Tu peux aussi créer des tables de service (par exemple une table de journal) qui font référence à la clé universelle sans risques de violation de clé.

L'identifiant universel est abstrait et n'a aucun sens pour l'utilisateur pour lequel on peut créer des clés "fonctionnelles". Cette approche simplifie la base et réduit les efforts de maintenance, en effet, si la clé fonctionnelle varie (les utilisateurs ont parfois des idées "géniales"), l'impact sur tes données sera moindre (clé primaire universelle préservée, intégrité référentielle non remise en question...).

@+

[SQLpro]

...rien ne t'interdit d'utiliser un seul générateur pour toutes tes tables sauf si la clé doit être nécessairement séquentielle pour une table donnée.

En effet, rien ou presque....

L'oubli systématique du développeur qu'il n'est pas tout seul au monde à utiliser le SGBDR... Quand vous aurez 1000 utilisateurs qui vont simultanément insérer dans des tables, bonjour la contention, les temps d'attente, voir les deadlock !!!

A +