【发布时间】:2010-12-28 13:17:04
【问题描述】:
我需要一个新的视角来了解如何设计一个可靠且高效的 SQL 数据库来存储多级数据数组。
这个问题适用于很多情况,但我想出了这个例子:
有数百种产品。每个产品都有未定义数量的零件。每个部分都由几个元素组成。
所有产品都以相同的方式描述。所有零件都需要相同的字段来描述它们(例如:价格、重量、零件名称),所有零件的所有元素也具有统一的设计(例如:元素代码、制造商)。简单明了。
一个元素可能只与一个部分相关,而每个部分只与一个产品相关。
我想出了三个表的想法:
Products:
--------------------------------------------
prod_id prod_name prod_price prod_desc
1 hoover 120 unused
下一个
Parts:
----------------------------------------------------
part_id part_name part_price part_weight prod_id
3 engine 10 20 1
最后
Elements:
---------------------------------------
el_id el_code el_manufacturer part_id
1 BFG12 GE 3
现在,选择所需的产品,从 PARTS 中选择所有 prod_id 相同的产品,然后从 ELEMENTS 中选择所有 part_id 匹配的产品 - 经过多次查询后,您已获得所有数据。
我只是不确定这是否是正确的方法。
我还有另一个想法,没有 ELEMENTS 表。
这会减少查询,但我有点担心这可能是蹩脚和不好的做法。
代替 ELEMENTS 表,PARTS 表中还有两个字段,所以它看起来像这样:
part_id、part_name、part_price、part_weight、prod_id、part_el_code、part_el_manufacturer
它们将是 text 类型,并且对于每个部分,有关元素的信息将存储为字符串,这样:
part_el_code | code_of_element1; code_of_element2; code_of_element3
part_el_manufacturer | manuf_of_element1; manuf_of_element2; manuf_of_element3
然后我们只需要从这些字段中分解()数据,然后我们得到数组,易于显示。 当然这并不完美,也有一定的局限性,但是这个想法可以吗?
我想出第二个变体的原因是第三个表格——元素——最终会变得相当大。如果有 10,000 个产品,每个产品有 4 个零件,平均每个零件有 3 个元素 - 这意味着元素表中必须有 120,000 行。老实说 - 我真的不知道这是否会导致性能问题。
我应该只采用第一个想法吗?或者也许有更好的方法来解决这个问题?
【问题讨论】:
-
查找 BOM“材料清单”
标签: sql arrays multidimensional-array