数据库设计：产品尺寸

对于B2B商店，我正在寻找最好的数据库设计。产品存储在数据库中，每个产品都有尺寸条。这个尺寸条的尺寸在产品可用的尺寸上是未知数。因此，在这个时候，我们知道产品，并且我们知道该产品可用的尺寸。在此之后，应该有可能在产品中添加未知数量的颜色，并且最后，对于每种颜色/尺寸组合，应该存储库存量。数据库设计：产品尺寸

下面，我已经为它做了数据库设计，但我认为它不是最好的解决方案。底线是将会输入订单。几乎每个订单都有多个产品和几乎所有的颜色/尺寸组合。有人可以帮助最好的数据库设计吗？

表结构：

sizebar 
-------- 
id, title 

sizebar_sizes 
-------- 
id, sizebar_id, size 

products 
-------- 
id, sizebar_id, title 

products_colors 
-------- 
id, product_id, color 

products_sizes 
-------- 
id, color_id, sizebar_sizes_id, quantity

来源

2014-01-22 Stefan

我想你想多到多的关系...... 产品和尺寸应该有一个数据透视表products_sizes。产品和颜色应该有一个数据透视表products_colors

另一个表可以包含在股票例如项目：与外键的productID，colorID和sizeID

来源

2014-01-22 15:33:24 Gregory

好的，这是一种可能性，但订单呢？我可以创建一个名为orders的表，对于每个唯一的productID，colorID和sizeId都带有一个新订单数量的行。但是，该表中的行数会快速增长，所以也许有更好的解决方案呢？ – Stefan

是真的，它可以变得非常大，但那是什么数据库是正确的？大量数据...您可以添加一种包含所有最新订单的缓存表，以便快速访问它们。或者，也许你可以将旧订单转储到一个文件中，这样你的表格仍然很小...通过索引你的订单表，你需要很多订单，然后它变慢，我认为缓存最新的“已使用”订单是你最好的打赌是否真的需要 – Gregory

IN_STOCK表我真的不能换我的头周围有什么“sizebar”是，但如果你说每个产品只有一个尺寸条，那么任何尺寸条数据都可以成为产品表的一部分。

那么你已经有了大小：

sizes 
-------- 
id, size

和颜色：

colors 
-------- 
id, color

产品仍然是一个通用的，高层次的概念：

products 
-------- 
id, title, sizebar_name

所以我们需要知道什么具体的变化可用吗？我把它叫做“项目”，但它可能是“available_products”或“变异”或什么：

items 
-------- 
id, item_id, color_id, size_id

我们还需要跟踪是有序的什么项目，所以我们需要的订单：

orders 
-------- 
id, client_id, order_date, shipping_type, etc etc

和

order_items 
---------- 
id, order_id, item_id, quantity

来源

2014-01-22 15:47:11

大小栏是多个大小的集合。因此，只有几个侧边栏，如： 1. s，m，l 2. m，l，XL 3. l，xl，xxl等因此，在生产产品后，它适合可用侧边栏之一。你的表格结构通常和我的一样。主要问题是：是否有可能减少order_items的数量，因为有一个大小条可以存储所有可用的大小？ – Stefan

所以sizebar可以是它自己的表格，但我认为它不应该如此附加到其余的。你可以用它来生成可用的物品，但是一旦衬衫是“XL蓝色SportsTeamXJersey”，它不再是关于它来自何种尺码的？ –

现在我想起它，您可能还需要一个inventory_items表来跟踪每件物品的数量，并确保它可以订购。 –

数据库设计：产品尺寸

回答

相关问题