Discussion :

[sekiryou]

SGBD: MySQL 4

Bonjours à tous,

À l'endroit où je travail, nous sommes en train de développer une base de données relationnelles et nous nous posions la question à savoir qu'est-ce qui est plus lourd (en frais d'espace) entre une donnée de type INT(3) ou une une clée étrangère qui pointe vers un ID?

Il y aura environ 10 données différentes contenu dans ces INT(3)... donc beaucoup de redondance si on met directement la donnée à l'intérieur.

Alors que si je mets ces données dans une autre table et que je pointe dessus avec une clé étrangère, j'évites cette redondance mais c'est là qu'émerge la question : "Qu'est-ce qui est plus lourds entre INT(3) et une FK?"

Bien sûr, ici on parle d'une table qui contiendra plus de 80 000 entrées...

Qu'est-ce que vous en pensez?

Sébastien

Merci

[qi130]

Alors que si je mets ces données dans une autre table et que je pointe dessus avec une clé étrangère, j'évites cette redondance...

Qu'est-ce que vous en pensez?

Que tu dois te perfectionner sur la notion de FK....

En effet, déclarer une FK, c'est uniquement mettre en place un mécanisme de contrôle.

Cela ne te dispense absolument pas de déclarer une colonne à l'identique de la FK, dans ta table "pointeuse" :

Les colonnes correspondantes de la contrainte dans la table et la table de référence doivent avoir le même type, pour éviter les conversions lors des comparaisons.

Un petit tour ici s'impose

[sekiryou]

Dans mon cours de Oracle mon prof m'avais expliqué que les données de FK ne sont pas vraiment stocké dans la table qui pointe, mais seulement une adresse d'où se situe cette donnée... Peut-être ai-je mal compris ?

En tout cas, peut-importe... je vais m'expliquer mieux (enfin, j'espères):

Qu'est-ce qui est moins gourmand en espace ? (Pensez toujours que normalement la table tbl_code devrait contenir environ 80 000 enregistrement!)

Ceci :

Ou ceci :


Le premier a une redondance évidente (qui se répercutera sur 80 000 enregistrements...) tandis que le deuxième utilise une FK.

Merci.

Sébastien

──────────────────
What we see now is like a dim image in a mirror, than we shall see face to face.

[qi130]

Bien évidemment, le 1er est - gourmand en espace, puisque tu fais l'économie de 2 INTEGERs, ainsi que de l'index sur la colonne de FK.

Cependant, même avec 80.000 lignes, ça représente peu de chose par rapport aux services rendus par la mise en oeuvre des FK :le contrôle est sous la coupe du serveur (c'est le moteur SGBD qui bosse) et cela assure un maximum de cohérence.

Alors que si tu implémentes la 1 ère solution, la cohérence sera à ta charge.

[sekiryou]

Ça ça répond à ma question, merci beaucoup.

a+

Sébastien
────────────────────
What we see now is like a dim image in a mirror, than we shall see face to face.