Le stockage de listes délimitées dans des colonnes de base de données est-il vraiment si mauvais ?

Question

Imaginez un formulaire Web avec un ensemble de cases à cocher (une ou toutes peuvent être sélectionnées). J'ai choisi de les enregistrer dans une liste de valeurs séparées par des virgules et stockées dans une colonne de la table de la base de données. Maintenant, je sais que la bonne solution consiste à créer une deuxième table et à normaliser correctement la base de données. Il est plus rapide de mettre en œuvre une solution simple et je souhaite obtenir rapidement une preuve de concept de l'application sans avoir à y consacrer trop de temps. Je pense que le gain de temps et le code plus simple en valent la peine dans mon cas. Est-ce un choix de conception raisonnable ou dois-je simplement le standardiser dès le départ ? Pour plus de contexte, voici

P粉948258958 · Answer

"Une des raisons est la paresse".

C'est un signal d'alarme. La seule raison pour laquelle vous devriez faire quelque chose comme ça, c'est parce que vous savez comment le faire « de la bonne manière », mais vous concluez qu'il y a une bonne raison de ne pas le faire.

Cela étant dit : si les données que vous choisissez de stocker de cette manière sont des données que vous n'aurez jamais besoin d'interroger, il peut alors être judicieux de les stocker de la manière que vous choisissez.

(Certains utilisateurs contesteront ma déclaration dans le paragraphe précédent, disant "on ne sait jamais quelles exigences pourraient être ajoutées à l'avenir". Ces utilisateurs sont soit mal informés, soit déclarent des croyances religieuses. Parfois, il est avantageux de travailler dur pour le exigences devant vous)

P粉545956597 · Answer

En plus de violer la Première forme normale, il existe de nombreux autres problèmes plus pratiques avec les colonnes de valeurs de groupe répétées stockées dans une seule liste séparée par des virgules :

Aucun moyen de garantir que chaque valeur est le bon type de données : aucun moyen d'empêcher 1,2,3,banana,5
Vous ne pouvez pas utiliser de contraintes de clé étrangère pour lier des valeurs à une table de recherche ; vous ne pouvez pas appliquer l'intégrité référentielle.
Impossible de forcer l'unicité : Impossible de bloquer 1,2,3,3,3,5
Vous ne pouvez pas supprimer une valeur d'une liste sans obtenir la liste complète.
La longueur de la liste stockée ne peut pas dépasser la longueur de la colonne de chaîne.
Il est difficile de rechercher toutes les entités d'une liste avec une valeur donnée ; vous devez utiliser une analyse de table inefficace. Vous devrez peut-être recourir à des expressions régulières, par exemple dans MySQL :
idlist REGEXP '[[:<:>:]]' 或在 MySQL 8.0 中：idlist REGEXP '\b2\b'李>
Il est difficile de compter les éléments dans une liste ou d'effectuer d'autres requêtes d'agrégation.
Il est difficile de connecter les valeurs aux tables de recherche auxquelles elles font référence.
Il est difficile de mettre la liste dans l'ordre.
Il est difficile de choisir un délimiteur qui est garanti de ne pas apparaître dans la valeur

Pour résoudre ces problèmes, vous devez écrire beaucoup de code d'application et réinventer les fonctionnalités plus efficaces que le SGBDR propose déjà.

Les listes séparées par des virgules sont fausses et j'en ai fait le premier chapitre de mon livre : SQL Anti-Patterns, Volume 1 : Éviter les pièges de la programmation de bases de données.

Il y a des moments où vous devez dénormaliser, mais comme @OMG Ponies l'a mentionné, ce sont des exceptions. Toute « optimisation » non relationnelle bénéficiera à un type de requête au détriment d’autres utilisations des données, alors assurez-vous de savoir quelles requêtes nécessitent un traitement spécial afin qu’elles méritent une dénormalisation.