Discussion :

[insane_80]

Bonjour à tous,

J'ai une question dont on n'a pas trouvé une réponse.

Prenons un exemple de deux entités : "Appareils" et "Types" avec une relation suivante :

"Appareils" <--(0,1)------(relation)-----(0.n)---> "Types"

sachant que la table "Types" contient une seule colonne avec peu d'enregistrements (3 ou 4) ET elle ne sera pas mise à jour.

Est-ce qu'il est mieux de garder cette conception qui respecte les normes OU bien j'enleve la table "Types" et j'ajoute directement un attribut "type" dans la table "Appareils" ? surtout que je vais gagner, plus ou moins, une rapidité d'execution des requêtes.

Cordialement.

[CinePhil]

Que seront ces types ?
- Des noms explicites de types tels que "ordinateur", "véhicule", "machine"... ?
- Des codes numériques ?
- Des codes alphanumériques ? Dans ce dernier cas, de combien de caractères ?

[insane_80]

Merci CinePhil pour la réponse,

Il s'agit des noms explicites : tablet - smartphone - watch

Cordialement.

[CinePhil]

Alors il vaut mieux une table séparée des types ; non pas avec uen seule colonne mais deux : un identifiant du type et le libellé du type :
tr_type_typ (typ_id, typ_libelle)

Dans la table des appareils, il y aura une clé étrangère référençant l'identifiant du type :
te_appareil_app (app_id, app_id_type...)

Ainsi, la clé étrangère ne prend qu'un minimum de place : 4 octets pour un entier, voire moins s'il y a très peu de type et pour toujours et que votre SGBD prévoit des types encore plus courts tels que le TINYINT.

Alors que si vous laissiez les noms des types en entier dans la table des appareils, vous occuperiez plus de place ("tablet" occupe au moins 6 octets, à raison d'un par lettre + un pour la longueur de la chaîne de caractères) et vous risqueriez d'avoir le même type écrit de plusieurs manières, ce qui ne faciliterait pas la recherche de tous les appareils d'un type.

Bref, il vaut mieux respecter la norme.

[insane_80]

Merci beaucoup CinePhil.