1

我知道将 JSON 存储在 MySQL 列中通常被认为是一个“坏主意”，因为它变得难以维护并且不容易搜索或以其他方式查询。但是，我觉得我在应用程序中遇到的场景是在我的 MySQL 表中存储 JSON 数据的合理用例。我确实在寻找答案，尤其是可以指出我可能忽略的任何困难的答案，或者是否有充分的理由避免我的计划，如果是这样，另一种方法。

手头的应用程序提供资源和库存管理，并支持构建程序集，其中可能包含无限数量的子程序集。

我有一个表，其中包含项目的所有元数据，例如它们的名称、sku、零售价、尺寸，以及最重要的问题：项目类型。项目可以是零件或装配体。对于定义为assembly的项目，它们的内容存储在另一个表中，该表item_assembly_contents的结构是预期的，使用parent_id列将子级链接到父级。如您所料，在任何时候，用户都可能决定在程序集中添加或删除项目，或者以其他方式修改程序集内容或将其完全删除。

这是上表描述的可视化表示，其中填充了数据，这些数据在组合时会创建一个包含另一个程序集的程序集。 项目和装配表结构 使用上述结构，从表中删除的任何项目也将通过 InnoDBitems在表中自动删除。item_assembly_contentsON DELETE CASCADE

这是一个非常简单的 JSON 格式的示例程序集，展示了单个子程序集结构。

{
   "id":1,
   "name":"Fruit Basket",
   "type":"assembly",
   "contents":[
      {
     "id":10,
     "parent_id":1,
     "name":"Apple",
     "type":"part",
     "quantity":1
      },
      {
     "id":11,
     "parent_id":1,
     "name":"Orange",
     "type":"part",
     "quantity":1
      },
      {
     "id":12,
     "parent_id":1,
     "name":"Bag-o-Grapes",
     "type":"assembly",
     "quantity":1,
     "contents":[
        {
           "id":100,
           "parent_id":12,
           "name":"Green Grape",
           "quanity":10,
           "type":"part"
        },
        {
           "id":101,
           "parent_id":12,
           "name":"Purple Grape",
           "quanity":10,
           "type":"part"
        }
     ]
      }
   ]
}

Fruit Basket 是一个程序集，其中包含一个名为“Bag o Grapes”的子程序集。在考虑订单和发货之前，这一切都非常有效。

以包含一个装配件的出境装运为例。在任何时候，用户都必须能够看到组件的内容，因为它们是在发货时定义的，这排除了简单地从itemsanditem_assembly_contents表中检索数据，因为这些表可能在发货后已被修改创建的。因此，装配内容必须与装运一起明确保存，以便以后可以查看它们，而与用户定义的库存（即表格）中装配的状态或仅存在无关。items

它将组装内容与装运内容一起存储，这让我有点困惑，在我看来，将数据存储在 JSON 中是一种可行的解决方案。了解有关此数据的以下几点至关重要：

  1. 它不会用于搜索
  2. 任何UPDATES都会简单地覆盖该行的内容
  3. 它最常用于填充客户端上的树视图，它将接受表中存在的 JSON，无需进行任何修改。

请参阅此图像以获得（希望）更清晰的数据可视化： 当前与建议的表结构

问题

  1. 这是一个合理的用例吗？我的担心没有意义吗？
  2. 有什么我看过的东西可能会回来咬我吗？
  3. 你能解释一下为什么我不应该继续我提出的模式吗？如果是的话......
  4. 你能提供一种替代方法吗？

与往常一样，非常感谢您抽出宝贵的时间，请随时要求澄清或补充信息。

更新 根据@Rowland Shaw的建议（如下），我提出了另一个建议的表结构，使用与 order_assembly_contents 表的自反或“兔耳”关系。请看下图： 更新了建议的表结构

我觉得这比直接存储 JSON 要优雅得多，因为数据更具有关系性和数据库友好性。检索数据并为客户端生成数据也应该很容易！请提供有关上述结构的任何输入！

4

2 回答 2

1

通常，对于订购系统，我期望类似

产品 -< OrderLine >- 订单

在您的情况下，您可以在您的产品上添加一个“兔子耳朵”关系来引用它自己。所以你outbound_shipment_contents输了name，换type了新的product。然后，您可以根据需要递归地构建要选择的项目树。

于 2013-09-19T16:06:48.300 回答
1

这似乎是一个标准的物料清单问题，并且有很多关于 SQL 和物料清单模式的好文章。我会避免使用 JSON 存储，因为它确实使依赖本机 SQL 的任何报告和详细连接功能变得复杂。对于您的应用程序，您可以在数据访问层内为 UI 构建 JSON。

恕我直言：在关系数据库中保持数据清洁、高度可访问和相关，在数据访问/低级业务层重新用于应用程序。

于 2013-09-19T16:17:37.703 回答