Lequel est le plus rapide: plusieurs lignes ou plusieurs colonnes?

Question

Sous MySQL, est-il généralement plus rapide / plus efficace / évolutif de renvoyer 100 lignes de 3 colonnes ou 1 ligne de 100 colonnes?

En d'autres termes, lors du stockage de nombreuses clés = > paires de valeurs liées à un enregistrement, est-il préférable de stocker chaque clé = > paire de valeurs dans une ligne séparée avec avec record_id en tant que clé, ou pour avoir une ligne par record_id avec une colonne pour chaque clé?

En outre, supposons également que les clés devront être ajoutées / supprimées assez régulièrement, ce qui, à mon avis, affecterait la maintenabilité à long terme de l’approche à colonnes multiples lorsque le tableau sera suffisamment grand.

Modifier: à préciser, par "régulièrement". Je parle de l'ajout ou du retrait d'une clé une fois par mois environ.

Answer 1

Vous ne devez jamais ajouter ou supprimer des colonnes régulièrement.

Answer 2

http://fr.wikipedia.org/wiki/Entity-Attribute-Value_model

Ce modèle présente de nombreux inconvénients et je ne l’utiliserais pas s’il existait une autre solution. Si vous ne connaissez pas la majorité (sauf quelques champs personnalisables par l'utilisateur) des colonnes de données dont vous avez besoin pour votre application, vous devez consacrer plus de temps à la conception et à la résolution.

Answer 3

Si vos clés sont prédéfinies (connues au moment de la conception), alors vous devriez placer chaque clé dans une colonne distincte.

S'ils ne sont pas connus au moment de la conception, vous devez alors renvoyer vos données sous forme de liste de paires clé-valeur à analyser ultérieurement en dehors du SGBDR .

Answer 4

Si vous stockez des paires clé / valeur, vous devriez avoir une table avec deux colonnes, une pour la clé (en faire une clé pour la table) et une pour la valeur (probablement pas du tout besoin de cette indexée) . Rappelez-vous, "La clé, la clé entière et rien que la clé".

Dans l’approche multi-colonnes, vous constaterez que votre table croît sans limite car la suppression de la colonne supprimera toutes les valeurs et vous ne voudrez pas le faire. Je parle d'expérience, ayant travaillé sur un système hérité comportant une table avec près de 1000 colonnes, dont la plupart étaient des champs de bits. Vous finissez par ne plus être en mesure de justifier la suppression de l'une des colonnes, car quelqu'un pourrait l'utiliser et la dernière fois que vous l'avez fait, vous travailliez jusqu'à 2 heures du matin pour revenir aux sauvegardes.

Answer 5

Premièrement: déterminez la fréquence d'accès à vos données. Si les données doivent toujours être extraites en une seule fois et que la plupart d'entre elles sont utilisées, envisagez de stocker toutes les paires de clés sous forme de valeur sérialisée ou sous forme de valeur xml. Si vous devez effectuer une analyse complexe sur ces données et que vous avez besoin des paires de valeurs, les colonnes sont acceptables, mais limitez-les à des valeurs sur lesquelles vous devez exécuter vos requêtes. Il est généralement plus facile de concevoir des requêtes qui utilisent une colonne pour un paramètre plutôt que la ligne. Vous trouverez également plus facile de travailler avec les valeurs renvoyées si elles sont toutes sur une seule rangée que plusieurs.

Deuxièmement: séparez les données les plus fréquemment consultées et mettez-les dans sa propre table et les autres données dans une autre. Soit dit en passant, 100 colonnes, c'est pourquoi je vous recommande de diviser vos données en fragments plus petits qui seront plus faciles à gérer.

Enfin: si vous avez des données qui peuvent fréquemment changer, vous devez utiliser créer la colonne (clé) dans une table, puis utiliser sa valeur de clé numérique contre laquelle vous souhaitez stocker la valeur de clé. Cela suppose que vous utiliserez la même clé plusieurs fois et que vous devriez accélérer la recherche lorsque vous allez effectuer votre recherche.