使用mysql进行库存管理的思路

我正在为一家出版公司创建一个数据库。该公司拥有约1300本书和约6-7个办公室。现在我已经创建了一个表，显示所有位置的库存项目。对于用户来说，该表应如下所示：

Book Name          Location1            Location2          Location3 ......
History              20000               3000               4354
Computers             4000               688                344
Maths                 3046               300                0
...

我已经有了一个书桌，里面存放着书的所有细节，我还有一个办公桌，里面有办公信息。现在，如果我创建一个显示上述信息的库存管理表，如果我以以下方式存储数据，我将在一个巨大的表中结束，并重复很多次：

Column1- Book_ID   Column2- Location_ID     Column3- Quantity
     1                  1                        20000
     1                  2                        3000
     1                  3                        4354
     2                  1                        4000
     2                  2                        688
   ...

因此，我认为这并不是存储数据的最佳方式，因为它最终会有

1300（图书）x7（位置）=9100行

。有没有更好的存储数据的方法。现在我可以在Books表中增加7列，但是如果我创建一个新位置，我将不得不向Books表中添加另一列

---

如果您有任何建议，或者您认为上述方法是否合适，我将不胜感激

不，那是最好的办法

你所拥有的是书籍和地点之间的多对多关系。在几乎所有情况下，这都作为两个主要实体之间的“关联”表存储在数据库中。在您的例子中，您还拥有关于该关联的其他信息，即“库存”或“数量”（或者，如果您像图形一样思考它，连接的大小或边权重）

所以，看起来你有很多“重复”，但实际上你没有。如果你试着用其他方式去做，它的灵活性就会大大降低。例如，使用现在的设计，添加另外1000本不同的书籍或另外20个位置不需要任何数据库模式更改

---

如果您试图将图书数量放入Locations表或Books表中，则需要更改数据库的布局，然后重新测试可能使用它的任何代码。

这确实是最好的方法；您有9100个独立数据要存储，因此确实需要9100行（实际上更少；数量为0的行可以省略）。另一种安排数据的方式是，在添加位置时，需要更改表的结构。

这是最常见（也是最有效）的解决方案。大多数框架，如Django、Modx和其他一些框架，只通过一个中间表，使用外键关系来实现许多关系

确保正确索引表

ALTER TABLE stock_management add index (Book_ID), add index (Location_ID)

---

但这将导致每次我添加另一个office时增加1300行？通常是的，但也可以，因为office有1300本书，所以您应该有1300行来存储这些信息，这并不一定；如果给定位置的给定书籍的数量为零，则可以省略该行。但是1300行是什么？这对于任何一个像样的数据库系统来说都算不了什么。@Namit-正如其他人所说，额外的几千行不会对数据库的性能产生太大的影响，特别是如果您在用于查询数据的字段上有索引的话。添加10000行可能会在插入行时产生影响，但即使如此，只要有索引，也应该没有任何问题。此外，关联表中没有一行意味着“无库存”或“0”，您可以限制只跟踪您拥有的库存而不是没有的库存所需的行数。除非您使用Pentium 4作为具有正确索引的服务器，否则InnoDB最多可以有1000万条记录。使用这个，这是正确且常见的解决方案。第一个建议是去掉location1、location2、location3列，并创建一个子表，显示图书id、LocationID和数量。在当前结构中，如果添加或删除位置，则必须返工数据库。如果使用mysql，请坚持使用标准数据类型。不要进入奇怪的枚举和集合，因为这不容易移植到新平台。@Vyktor-即使是奔腾4也应该可以处理这一数据量（假设查询量相对较低）@Brian-我很确定顶部的“表”是显示器（即应用程序UI）需要的样子，不是实际的DB模式。他清楚地说“表应该如下所示：”然后将位置1、2、3列为列。