Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Clé étrangère NULL
Bonjour,
Je prend l'exemple du parrainage dans une base de donnée MySQL. Est il préférable de faire une table d'association (à droite sur le schéma)
ou de faire une simple clef étrangère qui sera NULL dans 90% des cas (à gauche).
En gros ma question peut se traduire en : est ce que un champs (ici la clef étrangère) consomme de la place en mémoire inutilement en stockant un pointeur NULL ou autre ?
Merci d'avance.
Bonjour,
ces deux modèles physiques ne traduisent pas le même besoin au départ. Ce n'est pas une question d'optimisation mais de modélisation.
Le premier modèle exprime :
"Un membre peut être parrainé par un membre"
Tandis que le deuxième :
"Un membre peut être parrainé par un ou plusieurs membres"
Commencez par modéliser un MCD et définissez correctement les cardinalités entre vos entités. La traduction du MCD vers le MPD ne donnera qu'une solution par rapport à votre besoin.
Oui j'ai compris, c'est UN filleul qui a UN parrain
On peut aussi dire UN parrain a PLUSIEURS filleul
La question ici c'est : est ce qu'il est préférable de faire la "table d'association" (qui n'en ai pas vraiment une...) pour éviter des clef étrangère NULL ???
Non, ce que t'as dit vmolines, c'est que ton premier cas veut dire "Un filleul peut avoir un parrain, mais un seul", le second cas veut dire "Un filleul peut avoir un ou plusieurs parrains".Envoyé par Soap17
Ce n'est pas la même chose. Et c'est bien un problème de modélisation.
Sur la question de la place en mémoire, tout dépend des méthodes d'optimisations du SGBD. EN théorie, un champ même null consomme sa place dans la base. Après si le SGBD optimise la base, il peut très bien compresser les champs null.
Mais je ne pense pas que le problème de la place occupée soit un réel problème à ce niveau là.
--- Sevyc64 ---
Parce que le partage est notre force, la connaissance sera notre victoire
@Soap17
Hélas non, vous ratez quelque chose.
J'ai évoqué un membre qui pouvait avoir plusieurs parrains et non qu'un membre pouvait avoir plusieurs filleuls.
D'ailleurs il y a une faute de frappe dans ma phrase :
"Un même peut être parrainé par un ou plusieurs membres"
lire :
"Un membre peut être parrainé par un ou plusieurs membres".
Tout dépend de la PK de la table parrainage.
Parrainage(#id_filleuil, #id_parrain)
Répond au besoin et est identique à l'implémentation direct dans la table membre.
Pour aller plus loin...
http://blog.developpez.com/cinephil/...e-associative/
Après on adhère ou pas.
@Punkoff
C'est sûr mais tel que c'est présenté, je penche plus sur une petite lacune de modélisation. Proposer ce modèle physique va plus dérouter Soap17 qu'autre chose à mon sens.
D'ailleurs si on pouvait voir le MCD qui a conduit à ce MPD, j'aimerais bien savoir si on a une cardinalité 0,1 0,n ou une cardinalité 0,n 0,n sur l'association de parrainage entre membres.
Il manque en effet les multiplicités du diagramme de classes de Soap17 pour en déduire les règles de gestion qui conduisent au schéma.
Bien entendu, ce que je dis dans mon article avec pour illustration le MCD merisien s'applique aussi au diagramme de classes UML.
Si la règle de gestion est " Un membre peut être parraîné par un autre membre et un membre peut parraîner plusieurs autres membres ", alors le DC est le suivant :
membre -*--(parrain)--|
|--0..1--(parraîné)----------|
Et le MCD équivalent est celui-ci :
membre -0,1----parraîner
|--------------0,n----------|
Ce qui entraîne la création des tables suivantes :
membre (mbr_id, mbr_nom...)
parrainage (prr_id_filleul, prr_id_parrain)
Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
« Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
À la maison comme au bureau, j'utilise la suite Linux Mageïa !
Oui effectivement. Enfin bon ça serai l'inverse :
#parrain, #filleul
UN parrain a PLUSIEURS filleul et UN filleul a UN parrain.
Donc désolé tout le monde, je vais reposer ma question autrement :
peut on avoir des clef étrangère null (par convention j'entends) dans une table. Est ce propre... ?
La réponse à cette question me permettra de choisir entre les deux options.
PS : merci beaucoup pour vos réponses.
Vous pouvez déjà jeter un coup d'oeil à cette réponse donnée par fsmrel pour ce qui est du passage au MLD pour les association avec cardinalités 0,1-0,n : http://www.developpez.net/forums/d96...s/#post5422956
euh,
l'élément souligné est la pk, en partant de ce principe c'est bien filleul qui doit être la clef primaire et non l'inverse pour décrire le cas fonctionnel que vous amenez.
Oui effectivement désolé : #filleul, #parrain
J'ai lu ce poste ainsi que d'autres site, apparemment, les clef étrangère NULL se font dans certains cas.
Bon au final j'ai toujours pas de réponse. J'ai donc deux possibilités :
En fait, qu'est ce qu'il est préférable par rapport à deux choses :
- La faisabilité de certaines requêtes et leurs optimisations
- Le stockage mémoire.
vmolines a linké une très bonne explication de fsmrel concernant le choix de la solution à appliquer dans ce cas là
D’après ce que j'ai compris, il préfère la solution de droite (de mon schéma) ?
J'ai un peu de mal à lire son poste qui est assez poussé oO
Certains pronnent d'utiliser systématiquement des tables associatives. Perso, c'est pas mon cas, je n'ai pas encore été convaincu, peut-être parce que je n'ai pas toujours compris tous les arguments.
Pour moi dans le cas présent, la solution est relativement simple.
Un membre peut avoir un et un seul parrain, donc un clé étrangère dans la table membre suffit.
Un membre peut ne pas avoir de parrain, alors cette clé étrangère pourra être nulle pour certains enregistrements.
Un membre peut avoir un ou plusieurs parrain. Dans ce cas c'est la table d'association.
Pas de clé nulle ici, puisque les 2 clés étrangère formeront la clé primaire. Si un membre n'a pas de parrain, aucun enregistrement ne sera crée dans la table association.
--- Sevyc64 ---
Parce que le partage est notre force, la connaissance sera notre victoire
Oui mais dans ce cas particulier, il y aura 90% de case NULL, donc je trouve la table associative plus appropriée. Merci pour ta réponse ça confirme bien mes pensées.
Bonjour,
Je vous livre mon opinion. Il faut systématiquement éviter les clés étrangères "null" (que ce soit 90% des cas ou 0,1%). Vos requêtes seront plus rapides.
La création d'une table associative n'impacte pas votre client. Vous pouvez créer deux tables et une seule vue (CREATE VIEW). Votre client verra donc une seul table virtuel si vous le souhaitez.
Ensuite, il est évident que certains informaticiens crées des clés étrangères null. Si leurs bases de données sont minuscules, il est vrai que l'incidence est moindre. Si c'est une grosse base, pour une grande entreprise, un jour ou l'autre ça se cassera la gueule, et là il faudra supprimer les clés étrangères null. Cela peut coûter une vraie fortune à l'entreprise, voire plus.
ça ne coûte pas cher de travailler correctement.
Si vous avez encore le doute et que vous avez besoin de plus de certitude, créez 2 bases de données sur votre SGBDR, générez des lignes (en très grand nombre) dans chaque tables, exécutez vos requêtes sur les 2 BDD, puis mesurez le temps d'exécution de vos requêtes. La mesure des différentes solutions sera très précise et votre choix sera sur. Impossible de se tromper ainsi.
En résumé : pour des questions de perfs la table associative sera toujours mieux.
Fsmrel a une vision gros système et prône une modélisation très carrée.
Alors effectivement sur des très petites base (une base web de 5-10mo par exemple) la différence entre les deux structures ne se verra pas.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager