Discussion :

[arnaudlidz]

Bonjour,

Tout est dans le titre, je pense que ça dépend du contexte mais je développe une application avec des centaines et centaines de données.

Quels sont les pour et les contre de créer une base de données où dans les tables, une info = une colonne VS peu de colonnes avec un tableau pour plusieurs infos.

En vous remerciant.
Bien cordialement.
Arnaud

[aieeeuuuuu]

Bonjour,

Concernant le fait de mettre plusieurs données dans la même colonne probablement la dénormalisation la plus catastrophique, et il n'y a aucune "pour" à lui concéder...

une liste chargée de "contre" en revanche :
- oblige le moteur à manipuler plus de données que nécessaire (donc perte de performances)
- rend difficile voire impossible la pose d'indexes efficaces (donc perte de performances)
- oblige à des manipulation pour extraire les données voulues (donc perte de performances)
- rend les mises à jour plus compliquées (donc perte de performances)

En résumé, en "mélangeant" plusieurs informations dans la même colonne, les performances seront vite catastrophiques dés que la volumétrie augmentera.

La première forme normale impose que chaque colonne contienne une valeur atomique, et ne pas la respecter expose à bien des difficultés : au développeur pour écrire les requêtes d'une part, au moteur pour les exécuter d'autre part.

[arnaudlidz]

Je te remercie pour cette réponse très complète.

Il n'y a donc pas de soucis à avoir par exemple 100 colonnes pour une table ? Ou dans ce cas, faut-il utiliser deux tables ?

En tout cas, merci de ta réponse :-)
Bonne journée.
Arnaud

[aieeeuuuuu]

100 colonnes c'est énorme.

En général, avec une bonne modélisation, on n'arrive pas à ce stade. Et en effet, on découpe en plusieurs tables.

Mais sur le principe oui, il vaut mieux avoir 10 colonnes dans la table, qu'une seule qui "regroupe" 10 données différentes.

[arnaudlidz]

Je te remercie pour ces précieuses indications !

Bonne journée !

[CinePhil]

100 colonnes c'est énorme.

Je plussoie !

Commencez par modéliser vos données en écrivant des règles de gestion. Si besoin, pour vous aider, ensuite, il y a le forum Schéma.

Pour ne donner qu'un exemple, même si une personne est caractérisée par un nom, un prénom, une date de naissance, une adresse, un numéro de téléphone fixe, un autre mobile, une adrel, tout ceci sera découpé en plusieurs morceaux :
Ce qui est vraiment propre à la personne physique sont le nom, le prénom et la date de naissance (3 propriétés seulement).
L'adresse se décompose en plusieurs morceaux : les parties rue, le code postal, la ville, éventuellement le pays si on gère des étrangers. Pour ne pas répéter plusieurs fois la même ville dans plusieurs adresses, avec le risque de saisie d'une ville avec des orthographes différentes (Saint-Étienne, Saint Etienne, St Etienne...), il convient de séparer la ville et d'avoir une table de référence des villes. On peut aussi avoir la référence des codes postaux associés aux villes. Si on a des villes étrangères, il faut les associer à leur pays et on aura donc une table de référence des pays.
Dans mon petit énonce de base, on voit qu'une personne peut avoir plusieurs téléphones. On procédera donc à une séparation du téléphone de la personne.

Bref, ayez en tête qu'une base de données n'est pas un tableur ! On n'y enregistre pas toutes les informations dans un seul tableau de 100 colonnes.
Par contre, il peut tout à fait y avoir 100 tables de quelques colonnes (rarement plus de 10 colonnes par table).

[arnaudlidz]

Je vous remercie pour ce complément d'informations très détaillé.

Merci d'avoir pris le temps de me répondre ! :-)

J'étais effectivement dans cette vision de tableur, alors que ce n'est pas ça. Je m'en doutais un peu.

Donc en fait, il me faudra jouer sur les clés étrangères, c'est bien ça ?

En vous remerciant.
Arnaud

[CinePhil]

Donc en fait, il me faudra jouer sur les clés étrangères, c'est bien ça ?

Oui, mais commencez par modéliser les données avant de penser aux clés étrangères qui ne viendront que lors de la création physique de la base de données.

[StringBuilder]

Sans vouloir ouvrir de polémique, il y a quand même les types "XML" et "JSON" qui sont supportés nativement dans plusieurs SGBD et sont indexables de façon performante.

Après, cela dépend surtout de ce qu'on y met et de ce qu'on en fait.

Si c'est par exemple pour stocker des informations "raw" à savoir qui sont juste stockées telles qu'elles sans manipulation ou traitement particulier de recherche, alors aucune raison de les éclater en plusieurs colonnes qui n'auront aucune utilisé au niveau du SGBD.
En revanche, si on doit pouvoir faire des recherches, calculs, etc. sur ces données, il ne faut surtout pas les stocker sous cette forme.

En fait, il faut voir les types XML ou JSON un peu comme les types BLOB/CLOB/TEXT/IMAGE/VARCHAR(MAX)/VARBINARY(MAX) : ça sert à stocker des données brutes telles qu'elles sans aucune intelligence derrière ou presque.

Par exemple, si c'est pour stocker les caractéristiques de produits (dimensions, couleur, matière) alors il ne faut surtout pas utiliser cette méthode : les recherches sur ces attributs seront très lentes et les traitements complexe et limités.
En revanche, si c'est pour stocker des fichiers de paramètres associés à des données (par exemple les meta d'un document) et qu'on ne prévoit pas de recherche/traitement dessus (genre les meta d'un JPG, OSEF de faire une recherche sur l'ouverture du diaphragme de l'appareil qui a pris la photo) ce type de stockage est parfaitement adapté.

[SQLpro]

Ce n'est pas que pour le principe... C'est là règle absolue :
Première forme normale : toute information doit être ATOMIQUE (donc ne pas être "sécable" en plusieurs parties ayant chacune une sémantique dissociée, ce qui est le cas des listes, énumérations, tableau, structures, etc...)

A +

[SQLpro]

Sans vouloir ouvrir de polémique, il y a quand même les types "XML" et "JSON" qui sont supportés nativement dans plusieurs SGBD et sont indexables de façon performante.

Cela n'ôte pas l'intérêt de la première forme normale. En effet, un XML ou un JSON peut être un seul et même document. Par exemple un titre de propriété immobilière, un contrat de location, une police d'assurance...
Même si chacun de ces documents contient des données atomisable, l'ensemble du document constitue possiblement un tout indissociable.

A +