我正在一个网站上工作,这个网站就像一个注册卖家可以销售不同类型商品的市场。对于每个项目,都有共同的属性和可选的属性。看看以下内容,我将尝试解释。
实际上我们有一个名为 项目 的表格,其中包含所有待售商品,另一个名为 item_attr 其中包含常见的项目属性。因此,项目可以与0,1个或更多可选属性相关。
我们正在研究两种方法来存储每个项目的可选值,但两者都可能带来问题。
<案例A<案例B创建一个名为 item_additional_attr 的新表格,其中每条记录 将表示单个项目的附加属性。这里将 是 项目 之间的one-to-many relationship和 的 item_additional_attr 即可。这似乎是最“数据库友好”的解决方案,但我担心这个的大小 表可以有。如果 项 包含100.000条记录,则各自包含 item与5个可选属性的平均值相关, item_additional_attr 将包含500.000条记录。当然那将是一张巨大的桌子。
在 item_attr 中调用新的字段类型
TEXT
或BLOB
optional_attributes 。该字段将包含一组可选属性,并将在PHP中处理。当然阵列将是 存储为序列化或json编码。我认为这种方法可能会给某些查询带来问题,但在PHP中可以毫无问题地处理它。
我优先考虑webserver / db性能,但我也会避免查询问题。此外,其他属性仅用于显示表中的技术规范,绝不会用于过滤/排序。那么,在您看来,实现这一目标的最佳方式是什么?
答案 0 :(得分:1)
您可能想尝试使用EAV(实体属性值)表。基本上你会保留几张桌子。一个表应存储项目列表。其他表应该维护所有具有相似数据类型的属性。我创建了一个简单的模式来演示:
+---------+------------+
| item_id | item_name |
+---------+------------+
| 1 | Cell Phone |
| 2 | Shirt |
+---------+------------+
2 rows in set (0.00 sec)
+---------+--------------+----------------+-----------------+
| item_id | attribute_id | attribute_name | attribute_value |
+---------+--------------+----------------+-----------------+
| 1 | 2 | storage | 8GB |
| 1 | 3 | color | Gray |
| 2 | 4 | size | XL |
| 2 | 6 | shirt_color | Red |
+---------+--------------+----------------+-----------------+
4 rows in set (0.00 sec)
+---------+--------------+----------------+-----------------+
| item_id | attribute_id | attribute_name | attribute_value |
+---------+--------------+----------------+-----------------+
| 1 | 2 | price | 49 |
+---------+--------------+----------------+-----------------+
1 row in set (0.00 sec)
第一个表是项目列表。第二个表是项目列表&#39; varchar类型的属性。第三个表列出项目&#39; int类型的属性。这将允许可扩展的数据库将属性分散到多个表。唯一的缺点是为了获得一个项目及其所有属性,您需要进行的连接数量。可以通过php使用文本缓存方案来存储项目信息以提高性能。