Je me demandais si vous stockiez ou non une matrice en tant que chaîne JSON dans un champ de texte MySQL est une bonne pratique.
Je crée une facture qui permet à l'utilisateur d'ajouter un nombre illimité de produits à la facture. Lorsque le formulaire est soumis, il sort de tous les éléments vierges, mais je serai généralement laissé avec 2-5 articles en fonction. Chaque article a une SKU, un prix, un nom et une description.
Mes options de cette situation sont (1) pour créer une nouvelle table de produits, ajoutez chaque élément sous forme de ligne nouvelle, associez-le à la table de facturation et appelez les deux tables lors de l'accès à des données. Ou (2) stocker toutes les données du produit sous forme de champ texte JSON unique dans la table de facturation, puis je ne crée ni n'accédant à une autre table.
Depuis que je suis assez rigide avec la programmation MySQL, j'ai le sentiment que l'utilisation de JSON dans MySQL serait fronçée. Ai-je raison? Quelqu'un peut-il verser une lumière sur cela?
4 Réponses :
Si tout ce dont vous avez besoin est juste pour Store - alors ce n'est pas une mauvaise pratique.
Mais si vous devez effectuer une sorte de traitement, de tri ou quelque chose de similaire - vous devez la normaliser.
Génial, merci pour la réponse. Cela rend effectivement un sens parfait maintenant, et jusqu'à ce que je dois autoriser la recherche / le tri par des produits, je pense que je vais aller.
Si vous commencez à implémenter la logique de la base de données, vous avez fait quelque chose de mal. C'est ma règle de travail lorsque vous travaillez avec des bases de données SQL.
Je ne vois pas quand ce serait bien cependant. Vous avez essentiellement raison avec ce que vous dites, mais lorsque vous sauvegez des produits comme celui-ci, vous souhaitez savoir quelles commandes ont SKU XXX. Ou essayez d'ajouter facilement un produit à une commande. Ou faire quelque chose du tout vraiment. Il n'est pas vraiment difficile d'ajouter une table qui a les rangées-Per-Command, avec une pièce d'identité, une commande, un sku, un prix, un nom, un champ Descriptif. Peut-être encore plus plus tard. Je ne vois aucune raison de ne pas faire ça. Ce n'est pas comme se joindre à cette table causera des problèmes de performance.
@NANNE: Il s'agit simplement de la règle de rasoir d'Occam après: tant que nous pas besoin Nouvelle entité - nous ne le créons pas. Je sais que cela ne s'applique pas à cette question particulière, mais "ce n'est pas comme l'adhésion à cette table causera des problèmes de performance." --- Dites-le à Facebook? Tout a son propre coût.
Occams Razor dit que la meilleure Sollution est celle avec les moins de nouvelles hypothèses. Il serait juste de dire que si vous commencez à enregistrer des ordres que vous devriez les sauvegarder en tant que commandes. Donc, une commande a plusieurs rangées. Seulement quand il y a une raison de ne pas les sauver comme suit (par exemple: vous êtes Facebook ou que vous avez des problèmes de performance), vous devez penser à autre chose, comme la table JSON-IN-A-Table. Mais même alors vous voudrez peut-être une autre Sollution. Donc, Occams Razor dit: Faites-le simplement la méthode 'Par défaut' (normalisée), sauf si vous avez une raison de faire quelque chose comme ça.
@NANNE: La manière par défaut est celle qui ne bloque pas notre code, ses requêtes et notre schéma. Et stocker tout-in-JSON ne viole pas la 3ème NF (puisque nous traitons ce domaine en tant que propriété atomique) dans ce cas.
L'hypothèse supplémentaire dont vous avez besoin ici est que ces données sont réellement atomiques. Dans ce cas, vous avez raison, mais vous devez supposer que c'est et reste atomique. Tout ce que je dis, c'est qu'un prix, une SKU, un nom, etc. n'est pas une propriété par défaut, à moins que vous ne le suppose spécifiquement. Encore une fois, je suis d'accord avec vous que vous ne voulez pas trop concevoir, mais dans ce cas, mon opinion personnelle est que vous ne le faites pas, si vous avez ajouté une table supplémentaire. Il y a toute une gamme entre "ballonné" et "1 table supplémentaire".
Je ne suis pas un expert mysql, mais je pense que cela dépend de ce que vous voulez accomplir. Voulez-vous que les produits que vous avez enregistrés dans une facture soient consultables? Si oui, vous ferez mieux d'aller avec une structure de base de données relationnelle.
Si vous n'avez pas la nécessité de rechercher, vous pouvez stocker les données en tant que chaîne JSON ou simplement comme une matrice sérialisée et épargnez-vous d'utiliser JSON du tout.
dépend vraiment de vos besoins.
Si vous le stockez dans JSON, vous ne pourrez pas l'interroger à l'aide de SQL. Par exemple, je ne peux pas trouver toutes les factures qui ont acheté plus de 3 de produits A.
Parce que d'autres ont répondu à votre question plus directement, je vais adopter une approche frange et adresse stocker un nombre variable d'éléments qui viennent de supplier d'être une entité de base de données (SKU, prix, nom, description), car Json est peut-être bien maintenant, mais cela va conduire à une tonne de duplication de données.
Au lieu de cela, faites ce que vous avez dit et créez une table pour tous les produits. Créez ensuite une autre table pour Cela pourrait être un peu fastidieux en ce moment, mais lorsque toutes vos données sont dans des tables soignées et facilement interrogées, vous serez beaucoup plus heureux. Pensez au cauchemar de faire des rapports sur des millions de champs de texte avec Json. Absolument horrible.
Pour répondre à une partie de votre question: Non, je ne pense pas que ce soit factures_have_products . Vous pouvez ensuite tirer toutes les lignes de factures_have_products où l'identifiant de facture correspond, puis tirez toutes les lignes de produits dans laquelle l'ID de produit correspond aux lignes que vous avez tirées de FLOICES_HAVE_PRODUCTS < / code>.