Meilleure façon de stocker la taille du produit/les garanties dans une base de données?

Question

Je construis un magasin personnalisé et une chose sur laquelle aucun d'entre nous ici ne peut s'entendre est de savoir comment nous devrions stocker les champs de taille/quantité pour un produit. Je ne peux pas trouver facilement des informations à ce sujet et je me demande comment les gens ont abordé cela avant? Actuellement, nous envisageons soit de stocker les informations de taille/quantité complètes dans quelque chose comme JSON pour chaque produit dans un champ ou bien de créer une liste clé/valeur de taille variable qui est ensuite liée à un produit.

De quelle manière choisissez-vous de stocker cette information?

Answer 1

La méthode traditionnelle consiste à avoir une table de consultation d'unités, telle que «oz», combinée à une quantité qui n'est pas un nombre entier.

Answer 2

Je suppose que vous pouvez avoir plusieurs tailles/quantités non-calculables pour un produit.

par exemple. Pack, 12 Box, 22

Si vous faites cela dans une base de données, la pensée actuelle vous alors dit besoin de normaliser et de créer une nouvelle table contenant un lien vers le produit (Product_ID), une taille et une quantité . C'est ce que je ferais, mais je programme dans un langage qui n'a pas de paires JSON ou key/value.

Cependant - Je pense que la solution que vous choisissez dépend grandement de ce que vous ferez avec les valeurs de taille/quantité dans votre application. Sont-ils simplement affichés, ou vont-ils éventuellement être utilisés à d'autres fins? Aussi - y a-t-il une taille/quantité par défaut?

Answer 3

Il existe plusieurs façons de remédier, dont chacune augmente la complexité:

Ne pas les informations de l'unité de magasin:

L'enregistrement de l'élément peut stocker dans la description.

Article Tableau:

ID | Description  
---+--------------------------------- 
09 | Red Sox Tee Shirt (Case of 12) 
10 | Red Sox Tee Shirt (each) 
11 | 500lb Nylon Rope (per foot) 

ensuite sur la table de commande, il vous suffit de stocker un Item ID + Quantity où la quantité est une valeur décimale.

Stockez l'appareil dans le cadre de l'article

Description  | Unit | UnitPrice  
------------------+------+---------- 
Red Sox Tee Shirt | Case |  45.00 
500lb Nylon Rope | Foot |  0.25 

ensuite sur la table de commande, il vous suffit de stocker un Item ID + Quantity où la quantité est une valeur décimale.

unités magasin convertibles comme table enfant connexe de l'article

Article Tableau:

ID | Description  
---+---------------- 
10 | Red Sox Tee Shirt 
11 | 500lb Nylon Rope 

table Item_Unit

ID | Unit | UnitPrice 
---+--------+---------- 
10 | Each |  6.00 
10 | Case12 |  60.00 
11 | Foot |  0.25 
11 | Spool | 250.00 

Dans ce cas, l'enregistrement de la commande aurait besoin d'avoir Item ID + Unit + Quantity

plus souple et complexe - unités convertibles

Ce serait une extension de la dernière forme, mais où vous avez une table « Unité » qui stocke les unités, leur type d'unité (longueur, volume, etc. ...) et leur relation avec une unité commune. De cette façon, vous pouvez réellement convertir d'une unité à l'autre (1000 pieds == 1 bobine) par exemple.

Mais il est peu probable que vous ayez besoin de ce niveau de complexité.

Answer 4

Je utiliserais toujours des nombres entiers partout où je peux. par exemple. 100mm au lieu de 0.10m car il peut y avoir de petites erreurs lors du calcul sur des nombres à virgule flottante.