产品的MySQL数据库设计

Question

我正在开发一个Web应用程序，使人们可以跟踪他们将要走动的产品。

例子：我的仓库里有10个杯子。 我将5个杯子移至ShopA，将5个杯子移至ShopB。 然后，我将3杯咖啡从ShopA搬回我的仓库。

就我的数据库结构而言，我想到了一个看起来像这样的产品表：product_id location_id Quantity

但这似乎有点笨拙。 在示例中，我将在此产品的产品表中有1条记录，然后是2条，然后是3条。

我的问题是：在这种情况下，此产品有10行（每件商品有1行而不是数量字段）并更改每个产品的位置是否更好？ 但是，如果此表为许多用户存储产品，那么在很短的时间内，该表将有数百万行...我应该为此担心吗？

我对这种情况下的最佳实践非常感兴趣。

谢谢！

Answer 1

问题是这样的：您库存中的哪些项目具有唯一标识？ 每个杯子上都有不同的条形码吗？ （不要介意杯子；让我们谈谈书籍）。

如果您的商品具有唯一的标识符（它们自己的条形码或RFID标签），则每个商品肯定需要一行。 当您获取，迁移或出售每个项目时，您将更新其行以反映其新位置。

例如，考虑图书馆中的书籍。 每本书都是独一无二的。 即使图书馆拥有该书的两个副本，也要分别处理。

另一方面，如果项目是可互换的（例如书店中的书籍副本），则可以进行简化的假设，即每个位置的每个项目都有一个项目计数。 书店里有五本最新哈利波特的书架。 当客户购买一本时，书店现在有四本。 当书店收到另一个装满的书时，它怎么有14册。

当然，这两种方法在重新定位库存时发生的DBMS事务的性质上有很大不同。 第二种方法看起来更像是重复记录簿记，而第一种方法像是产品普查。

考虑到如今数据存储的价格便宜，以及诸如RFID标签之类的独特标识符的泛滥，使用第一种方法可能会更好，因为每种方法都需要一行。

Answer 2

我认为一个简单的问题是，您是否想要更轻松的可编程性，还是更小的数据库？ 如今的存储如此便宜，而且越来越便宜，答案很明确：为自己节省大量的精力，并以将来为您提供最简单的代码的方式构建数据库。

Answer 3

我同意奥利·琼斯（Ollie Jones）的回答，但我想补充一点，“重复输入簿记”方法将具有以下行：

CREATE TABLE [Transactions] (
    [FromLocationId] /* foreign key to the locations */,
    [ToLocationId] /* ditto */,
    [Amount]
)

这样，每个事务只有一行。

Answer 4

如果您为每个项目保存1行：

• 没有并发锁。 快速插入/删除项目。 最简单的设计。

如果用数量保存项目：

• 并发更新更为复杂。 为了避免块，我们在表中添加了新字段，并在每次更新之前对其进行验证/设置。

数百万行-MySQL没问题

另请参见NoSQL-store ：可能对您而言效率更高。

PS对不起，我的英语。

Answer 5

在我看来，无论什么情况->您只有两种方法可以遵循：

• 并发性
• 没有同步

简而言之，这意味着您将在数据库中记录很多行，或者仅记录该项目的数量。

我特别希望只记录该项目的数量（使用并发性），有时管理起来会更复杂，但是照顾它的好例行程序将来不会给您带来麻烦，因为您的数据库不会如果您不打算使用并发性，那么会长大。

但是，当然，mysql可以毫无问题地轻松保存数百万行，这取决于您决定最佳性能。

预测您的数据库增长，进行测量，如果数据库在短时间内会增长很多，那么最好使用并发方法。

祝好运！