MySQL 组件 stock/order 系统的结构
MySQL structure for component stock/order system
我正在为我的电子制造公司制作一个组件订购系统。
到目前为止，我们一直在使用 Excel，但它开始变得非常复杂，我们看到 php/mysql 可以相当简单地完成这项工作。我是一名具有一定编程经验的电子专家，请耐心等待。
我已经开始制作组件库，如图 1 所示。
这工作正常。当我想模仿这个传播时出现问题sheet（图2）。
在这里，当有新订单时，我会为每件购买的商品添加库存。每次都会创建一个新列。在这张图中，CC1110F32RHHR 的 6000 个订单有 3 个。如何使用 MySQL 继续解决这个问题？在此处添加新列似乎不是一个好的解决方案。
图片1：http://i.stack.imgur.com/CiOhx.jpg
图二：http://i.stack.imgur.com/aCRgR.jpg
编辑：
感谢所有的快速反馈。我可以看到我对这个问题的解释不够好。
在 excel sheet（图片 2）中，当我单击一个按钮时，新库存将添加到每个制造商零件编号中。我想在 PHP 中提出相同的观点。数据不必以这种方式构建。
我面临的问题是我有数百个制造商零件号，我想定期存储每个零件号的新信息（订购日期、当天购买的库存）。但我认为这样做的唯一方法是为每个人都有一个单独的列。一定有别的办法吗？
EDIT2:
尝试在下面的文本中做一个例子。
如果你在这里看到，当我这样做时，我只能下一个订单，然后我就不能在其中添加更多信息（不添加名为 orderid2 等的新列）。很明显，这不是构建 table 的正确方法。在我的不同 tables 中，mpn 是唯一标识符，因此我始终可以从组件库中获取有关所选 mpn 的更多信息。
mpn date orderedstock orderid
part1 1.1.15 1500 1
part2
part3 1.1.15 750 1
part4
part5
...
part274
你是对的。添加列正在更改数据库架构。这些操作通常并不意味着正常的数据输入。关系数据库针对具有固定 table 结构的表格数据进行了优化。
因此，您组织数据的方式应使新数据出现在新行中，而不是新列中。
您的数据看起来非常结构化，因此关系方法似乎是个不错的选择。如果您在这些领域有很大的灵活性，您可能希望研究 NoSQL 解决方案，这些解决方案通常侧重于高效的列 aggregation/Queries。
抱歉，这是一个相当笼统的回答，但您的问题不够具体，无法详细说明。
我正在为我的电子制造公司制作一个组件订购系统。 到目前为止，我们一直在使用 Excel，但它开始变得非常复杂，我们看到 php/mysql 可以相当简单地完成这项工作。我是一名具有一定编程经验的电子专家，请耐心等待。
我已经开始制作组件库，如图 1 所示。
这工作正常。当我想模仿这个传播时出现问题sheet（图2）。
在这里，当有新订单时，我会为每件购买的商品添加库存。每次都会创建一个新列。在这张图中，CC1110F32RHHR 的 6000 个订单有 3 个。如何使用 MySQL 继续解决这个问题？在此处添加新列似乎不是一个好的解决方案。
图片1：http://i.stack.imgur.com/CiOhx.jpg
图二：http://i.stack.imgur.com/aCRgR.jpg
编辑：
感谢所有的快速反馈。我可以看到我对这个问题的解释不够好。
在 excel sheet（图片 2）中，当我单击一个按钮时，新库存将添加到每个制造商零件编号中。我想在 PHP 中提出相同的观点。数据不必以这种方式构建。
我面临的问题是我有数百个制造商零件号，我想定期存储每个零件号的新信息（订购日期、当天购买的库存）。但我认为这样做的唯一方法是为每个人都有一个单独的列。一定有别的办法吗？
EDIT2:
尝试在下面的文本中做一个例子。 如果你在这里看到，当我这样做时，我只能下一个订单，然后我就不能在其中添加更多信息（不添加名为 orderid2 等的新列）。很明显，这不是构建 table 的正确方法。在我的不同 tables 中，mpn 是唯一标识符，因此我始终可以从组件库中获取有关所选 mpn 的更多信息。
mpn date orderedstock orderid
part1 1.1.15 1500 1
part2
part3 1.1.15 750 1
part4
part5
...
part274
你是对的。添加列正在更改数据库架构。这些操作通常并不意味着正常的数据输入。关系数据库针对具有固定 table 结构的表格数据进行了优化。
因此，您组织数据的方式应使新数据出现在新行中，而不是新列中。
您的数据看起来非常结构化，因此关系方法似乎是个不错的选择。如果您在这些领域有很大的灵活性，您可能希望研究 NoSQL 解决方案，这些解决方案通常侧重于高效的列 aggregation/Queries。
抱歉，这是一个相当笼统的回答，但您的问题不够具体，无法详细说明。