recherche

Maison  >  Questions et réponses  >  le corps du texte

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

<p>Imaginez un formulaire Web avec un ensemble de cases à cocher (dont 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. </p> <p>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. </p> <p>Je pense que le gain de temps et la simplification du code en valent la peine dans mon cas. Est-ce un choix de conception raisonnable ou dois-je simplement standardiser cela dès le départ ? </p> <p>Pour plus de contexte, il s'agit d'une petite application interne qui remplace essentiellement un fichier Excel stocké dans un dossier partagé. Je pose également cette question parce que je pense nettoyer le programme et le rendre plus facile à maintenir. Il y a certaines choses dont je ne suis pas très satisfait, dont l'une fait l'objet de cette question. </p>
P粉020556231P粉020556231475 Il y a quelques jours486

répondre à tous(2)je répondrai

  • P粉948258958

    P粉9482589582023-08-28 11:49:53

    "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)

    répondre
    0
  • P粉545956597

    P粉5459565972023-08-28 09:02:45

    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 '[[:<:]]2[[:>:]]' 或在 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.

    répondre
    0
  • Annulerrépondre