当前位置:Gxlcms > PHP教程 > 请问关于商品标签的数据库设计及多层关联逻辑?

请问关于商品标签的数据库设计及多层关联逻辑?

时间:2021-07-01 10:21:17 帮助过:79人阅读

普通的一个商品对应多个标签的设计只需要3个表(商品表、标签表、关联表)就能解决,我这个情况有些复杂,烦请各位知友帮我出出主意

简单介绍下背景,项目是一个第三方展览平台,就是本身不做展览,但负责联通展品、参展人、品牌方、展馆、展览会的这么一个平台,类似中介这样的。参展人或品牌方可以在上面提交自己的展品;有空余场地的人也可以在上面出租自己的场地作为展馆;然后就凑在一起举办展览会。也许我这么说有些莫名其妙,大家不要在意,有协议在身我也不好再细说下去了。

按照目前的需求,上传展品时允许自定义标签,不限数量。参展人和品牌方本身不带标签功能,而是通过“参展人(品牌方)-展品-标签”的方式关联,也就是说参展人的标签取决于他上传的所有展品的标签,品牌方同理。
而展览会本身也不带标签功能,通过“展览会-参展人-展品-标签”的方式关联。展览会有开始时间和结束时间两个字段,超过结束时间则视为展览结束。

问题来了,需求是在展览会列表中,根据标签筛选;而且未参展的标签不显示。

我顿时就懵逼了,按照这个需求,我得先找出所有正在展出的展览会(即已开始且未结束)的参展人或品牌方,然后查出他们所有的展品,然后查出这些展品所有的标签, 然后去除重复的,最后显示。这在未来数据量大了之后将会多么恐怖

我不知道是这个需求本身就不合理,还是说其实有很好的解决办法但我想不到。请各位知友不吝赐教

补充一下,由于对方的一些限制,无法使用诸如redi、memcache、mongodb之类的,只能用mysql

回复内容:

普通的一个商品对应多个标签的设计只需要3个表(商品表、标签表、关联表)就能解决,我这个情况有些复杂,烦请各位知友帮我出出主意

简单介绍下背景,项目是一个第三方展览平台,就是本身不做展览,但负责联通展品、参展人、品牌方、展馆、展览会的这么一个平台,类似中介这样的。参展人或品牌方可以在上面提交自己的展品;有空余场地的人也可以在上面出租自己的场地作为展馆;然后就凑在一起举办展览会。也许我这么说有些莫名其妙,大家不要在意,有协议在身我也不好再细说下去了。

按照目前的需求,上传展品时允许自定义标签,不限数量。参展人和品牌方本身不带标签功能,而是通过“参展人(品牌方)-展品-标签”的方式关联,也就是说参展人的标签取决于他上传的所有展品的标签,品牌方同理。
而展览会本身也不带标签功能,通过“展览会-参展人-展品-标签”的方式关联。展览会有开始时间和结束时间两个字段,超过结束时间则视为展览结束。

问题来了,需求是在展览会列表中,根据标签筛选;而且未参展的标签不显示。

我顿时就懵逼了,按照这个需求,我得先找出所有正在展出的展览会(即已开始且未结束)的参展人或品牌方,然后查出他们所有的展品,然后查出这些展品所有的标签, 然后去除重复的,最后显示。这在未来数据量大了之后将会多么恐怖

我不知道是这个需求本身就不合理,还是说其实有很好的解决办法但我想不到。请各位知友不吝赐教

补充一下,由于对方的一些限制,无法使用诸如redi、memcache、mongodb之类的,只能用mysql

这样的需求用关系数据库实现再合适不过了。
根据你的描述,参见如下数据模型:

根据Tag查询Exhibition:

SELECT e.GalleryId, e.StartTime, e.EndTime
FROM Exhibition e
WHERE EXISTS (
    SELECT 1
    FROM PresentedProduct p
    JOIN ProductTag pt ON pt.ProductId = p.ProductId
    WHERE TagId = 'T1' AND p.GalleryId = e.GalleryId AND p.StartTime = e.StartTime
    )

我对具体需求不太了解,所以你需要根据具体情况设计数据模型。
在逻辑设计的阶段,不要考虑物理实现,数据量等问题,而是要忠于需求,设计出符合逻辑的逻辑数据模型。
在物理实现时,根据需求建索引,甚至分表,等等。
不要过早优化。

以下是个人观点:

  1. 慎用人工Id (Surrogate Key)
    如果每个表都用一个人工Id,很难分析出符合逻辑的数据模型,数据完整性也得不到保证,而且一个查询往往需要很多JOIN。

  2. 数据量
    关系数据库的处理能力是很强的,对于几百万级别的表,只要索引设好了,返回相对少量的数据是很快的。如果需要返回的数据量也大,那你不管怎么设计都需要花费很多时间。不要把你的项目想象成google或者亚马逊,那样的话大部分团队根本没时间,也没能力开发出来。即使项目真的很成功,到时再重构也来得及。把经典的关系数据库学好了,足够应付大部分项目。

人气教程排行