Discussion :

[insane_80]

Bonjour à tous,

J'ai une problématique dont j'ai besoin d'avoir la réponse de votre part.

J'ai une grande table "Appareils" d'environ 60 colonnes. Ces colonnes représentent les caractéristiques des appareils.

Pour certaines caractéristiques, ils admettent une valeur parmi une petite liste prédéfinie. Prenons l'exemple d'un smartphone : (type_carte_sim, système_exploitation, type_carte_memoire, technologie_ecran, ....etc). La valeur de chaque colonne est parmi trois ou quatre valeurs d'une liste.

Ils ont dit qu'on doit respecter les normes pour ne pas avoir une grande table. Pour cela, j'ai créé des petites tables ayant la relation n....1 avec la table "Appareils".

1- Mais finalement, on aura le même nombre de colonnes dans la table "Appareils", parce que les clés étrangères des petites tables vont migrer vers cette table. Donc, la table reste toujours grande !

2- Pour afficher toutes les caractéristiques d'un smartphone, la requête correspondante va contenir beaucoup des jointures, donc elle va prendre plus de temps en exécution.

Merci de m'aider sur ces deux points SVP.

Cordialement.

[Richard_35]

Bonjour Insane_80,

Avant de s'intéresser à la taille de la table (qui, certes, peut avoir son importance), il faut comprendre l'intérêt des tables de référence.

Dans ton exemple, pour un smartphone, l'attribut système_exploitation pourra avoir les valeurs "Androïd", "Windows Phone", etc... Si les valeurs ne sont pas dans une table de référence, alors l'attribut système_exploitation pourra avoir les valeurs "Androïd", "Anroïd", "Windows Phone", "Windows", etc... suite à des erreurs de saisie (ou autre). En conséquence, les valeurs "Androïd", "Windows Phone", etc... doivent être choisies dans une liste déroulante qui présente les valeurs imposées de la table de référence. Sinon, tes requêtes futures considéreront "Androïd", "Anroïd", "Windows Phone" et "Windows" comme quatre systèmes d'exploitation différents alors qu'il n'y en a que deux.

Maintenant, c'est vrai, nous ne connaissons pas grand chose de ton projet...

[CinePhil]

60 colonnes, ça fait beaucoup !

Je subodore que toutes les colonnes ne concernent pas tous les appreils et qu'il y a donc des appreils pour lesquels certaines colonnes sont à NULL ?

[insane_80]

Merci Richard_35 pour l'importance des tables de référence, vous avez raison, c'est très important.

Merci CinePhil pour votre réponse.

60 colonnes, ça fait beaucoup !

Je subodore que toutes les colonnes ne concernent pas tous les appreils et qu'il y a donc des appreils pour lesquels certaines colonnes sont à NULL ?

Le grand nombre des colonnes est à cause du respect des normes (je pense !) :
1- Je ne veux pas mettre plus d'informations dans la même colonne. Par exemple pour les dimensions : à la place de faire une seule colonne contenant une chaine de caractères (139.3 x 69.7 x 6.7 mm. par exple), j'ai fait trois colonnes de type entier : Height, Width et Thickness. La même chose pour la résolution de l'écran : il y a deux valeurs (H et W). Il y a aussi deux "talk time" : en 2g et 3g. Il y a aussi des caractéristiques de caméra .... Donc, il y a beaucoup.

2- Il y a certaines colonnes admettant, soit Oui ou Non (je n'ai pas donc des NULL)

Tous ça va augmenter bien sûr le nombre de colonnes. Vous êtes d'accord ?

Cordialement.

[CinePhil]

Ma supposition était que votre table nommée "appareil" ne contenait pas que des téléphones et que certaines colonnes concernent d'autres appareils que les téléphones n'ayant rien à voir avec la 2g ou la 3g ou la taille d'un écran.
Si toutes les colonnes sont remplies alors OK.

[Richard_35]

Bonjour Insane_80 et Philippe,

C'est vrai que :

60 colonnes, ça fait beaucoup !

==> et ça fait beaucoup, car il n'y a qu'une seule table qui regroupe plusieurs appareils avec des attributs différents... de sorte que les attributs qui ne concernent pas certains appareils ont une valeur NULL... ce qui n'est pas très bon !

L'objectif d'une application n'est pas de comporter le moins de table(s) possible(s), mais de tourner correctement en évitant les "bidouilles" de toutes sortes... si possible.

Le cas que tu présentes relève, typiquement, de l'héritage :



Donnant :

• Appareil(IdAppareil, Attributs_communs_a_tous_les_appareils...) ;
• Smartphone(#IdAppareil, Attributs_propres_aux_smartphones...) ;
• Camera(#IdAppareil, Attributs_propres_aux_Camera...) ;
• ...

La contrainte "XT" voulant dire qu'un appareil ne peut être, à la fois, un smartphone ET une caméra.

[insane_80]

Merci beaucoup Richard_35 et CinePhil pour votre aide.

La table "Appareils" contient seulement les smartphone et tablets, et ces derniers ont les mêmes caractéristiques je pense ... donc, il n'y a pas des NULL dans les colonnes. Et je veux dire par la caméra, c'est la caméra du smartphone/tablet lui-même.

Cordialement.

[CinePhil]

C'est bien comme ça que j'avais compris votre précédent message...

On peut quand même se poser la question de l'utilité de détailler autant !

Par exemple pour les dimensions : à la place de faire une seule colonne contenant une chaine de caractères (139.3 x 69.7 x 6.7 mm. par exple), j'ai fait trois colonnes de type entier : Height, Width et Thickness. La même chose pour la résolution de l'écran : il y a deux valeurs (H et W)

Est-ce que l'utilisateur final va chercher une longueur de smartphone ou une largeur d'écran ?

Autre question à se poser : allez-vous récupérer systématiquement toutes les colonnes de la table ou bien certaines colonnes ne seront-elles demandées que rarement ?

En cas de grande table, il pourrait être pertinent de couper les informations en deux tables :
- une table avec les caractéristiques courantes et systématiquement récupérées par l'application ;
- une table avec les autres caractéristiques plus rarement demandées.

Ainsi, la recherche, par exemple d'une liste de smartphones dans une gamme de prix ne sera pas pénalisée par une grosse table de 60 colonnes. La seconde table ne serait interrogée que lorsque l'utilisateur sélectionne un smartphone pour en voir les caractéristiques détaillées.

Cependant, je pense que la différence ne se fera sentir qu'à partir de quelques dizaines de milliers de lignes dans la table, voire des centaines de milliers.

Quoiqu'il en soit, j'espère que vous avez compris le principe de la spécialisation (héritage) présenté par Richard_35.

Revenons cependant à votre question d'origine...
Oui, il est mieux d'avoir une table de référence plutôt qu'une colonne avec un grand nombre de fois la même valeur textuelle.
1) Ça prend moins de place et la table sera plus légère.
2) Ça évite les erreurs de saisie ou les manières différentes d'écrire la même chose et qui pourrait pénaliser la recherche d'appareils sur ce critère.

[insane_80]

Est-ce que l'utilisateur final va chercher une longueur de smartphone ou une largeur d'écran ?

Actuellement dans le cahier des charges, il n'y aura pas de recherches sur ces petits détails des caractéristiques, c'est seulement au niveau par exemple du système d'exploitation, Résolution de l'écran ....etc. MAIS dans le future, on peut aller avoir ce besoin (recherches sur longueur, largeur, ....).

Autre question à se poser : allez-vous récupérer systématiquement toutes les colonnes de la table ou bien certaines colonnes ne seront-elles demandées que rarement ?

Effectivement, la première affichage des caractéristiques sera seulement sur les caractéristiques très connues (système d'exploitation, Taille de l'écran, Résolution caméra, ...) et l'affichage de tous les détails est à la demande de l'utilisateur.

Est-ce que dans ce cas, on peut couper les informations en deux tables ayant la relation 1....1 entre elles ? Est-ce que cela respecte les normes de la modélisation ?

Quoiqu'il en soit, j'espère que vous avez compris le principe de la spécialisation (héritage) présenté par Richard_35.

Oui j'ai compris ce proncipe d'héritage, mais dans mon cas, je pense qu'il n'y a pas d'héritage.

Cordialement.

[CinePhil]

Effectivement, la première affichage des caractéristiques sera seulement sur les caractéristiques très connues (système d'exploitation, Taille de l'écran, Résolution caméra, ...) et l'affichage de tous les détails est à la demande de l'utilisateur.

Est-ce que dans ce cas, on peut couper les informations en deux tables ayant la relation 1....1 entre elles ? Est-ce que cela respecte les normes de la modélisation ?

C'est exactement ce que je préconise.

appareil (app_id, [caractéristiques les plus fréquemment demandées])
appreil_details (ad_id_appareil, [caractéristiques rarement demandées])

Nota : app_id est à la fois clé primaire et clé étrangère dans la seconde table.

Il suffit ensuite de faire une vue pour réunir toutes les caractéristiques des appareils :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
CREATE VIEW v_appareil_complet AS
SELECT a.*, d.*
FROM appareil a
INNER JOIN appareil_detail d ON d.ad_id_appareil = a.app_id

D'ordinaire, j'évite la guerre des étoiles mais je conçois qu'avec 60 colonnes on puisse avoir envie d'éviter de les écrire toutes, ce qui fait quand même une grosse requête. D'autant que le but est bel et bien dans cette vue d'avoir toutes les colonnes des deux tables.

[insane_80]

Merci CinePhil.
Et pour votre remarque suivante :

Est-ce que l'utilisateur final va chercher une longueur de smartphone ou une largeur d'écran ?

Pour l'exemple de la résolution de l'écran (Exp: 1080 x 1920 pixels), est-ce qu'il est mieux de faire une seule colonne ou deux colonnes ?

Cordialement.

[CinePhil]

Ben j'aurais tendance à dire que ce qui intéressera l'utilisateur, c'est la dimension globale, d'ailleurs généralement exprimée en pouces (de diagonale) pour ce qui est d'un éventuel critère de recherche. Ensuite, pour que l'utilisateur se représente concrètement ce qu'est un écran de 5", l'information complète longueur x largeur me semblerait suffisante. Ou alors si vous utilisez deux colonnes, c'est pour calculer la diagonale en pouces automatiquement peut-être ?

J'ai essayé de vous aiguiller sur les bonnes questions à se poser avant d'enregistrer trop de détails qui ne serviront peut-être jamais.

[Richard_35]

Bonjour Insane_80 et Philippe,

Pour l'exemple de la résolution de l'écran (Exp: 1080 x 1920 pixels), est-ce qu'il est mieux de faire une seule colonne ou deux colonnes ?

==> personnellement, je préfère qu'un attribut reste spécialisé. Donc, il me semble préférable de créer deux colonnes distinctes, sinon cet attribut sera une zone de texte difficilement exploitable.

Plusieurs cas possibles :

• liste déroulante sur les largeurs (ou longueurs) possibles (une tables des largeurs et une table des longueurs) ;
• création de requêtes sur la largeur (ou la longueur), uniquement ;
• ...

Nous parlons, ici, des tailles d'écran... il y a bien d'autres attributs pour lesquels il serait dangereux de les regrouper en une seule zone texte...

[insane_80]

Vous avez raison Richard_35. Il est danagereux de regrouper plusieurs informations en une seule colonne (chaîne de caractères). Il sera dificile, par la suite, de tavailler sur une de ces informtions toute seule.

Mais, pour la résolution des écrans, et après une recherche sur Internet (surtout Wikipedia), j'ai observé que la liste de ces résolution est limité (au moins dans le marché actuellement). On trouve : VGA (640x480) - FHD (1920x1080) - .... etc.

Donc, je pense qu'il est mieux de créer une table de référence ayant une colonne représentant cette liste des résolutions. Cette colonne est un texte.

Cordialement.