普通的一个商品对应多个标签的设计只需要3个表（商品表、标签表、关联表）就能解决，我这个情况有些复杂，烦请各位知友帮我出出主意
简单介绍下背景，项目是一个第三方展览平台，就是本身不做展览，但负责联通展品、参展人、品牌方、展馆、展览会的这么一个平台，类似中介这样的。参展人或品牌方可以在上面提交自己的展品；有空余场地的人也可以在上面出租自己的场地作为展馆；然后就凑在一起举办展览会。也许我这么说有些莫名其妙，大家不要在意，有协议在身我也不好再细说下去了。
按照目前的需求，上传展品时允许自定义标签，不限数量。参展人和品牌方本身不带标签功能，而是通过“参展人（品牌方）-展品-标签”的方式关联，也就是说参展人的标签取决于他上传的所有展品的标签，品牌方同理。
而展览会本身也不带标签功能，通过“展览会-参展人-展品-标签”的方式关联。展览会有开始时间和结束时间两个字段，超过结束时间则视为展览结束。
问题来了，需求是在展览会列表中，根据标签筛选；而且未参展的标签不显示。
我顿时就懵逼了，按照这个需求，我得先找出所有正在展出的展览会（即已开始且未结束）的参展人或品牌方，然后查出他们所有的展品，然后查出这些展品所有的标签， 然后去除重复的，最后显示。这在未来数据量大了之后将会多么恐怖
我不知道是这个需求本身就不合理，还是说其实有很好的解决办法但我想不到。请各位知友不吝赐教
补充一下，由于对方的一些限制，无法使用诸如redi、memcache、mongodb之类的，只能用mysql
普通的一个商品对应多个标签的设计只需要3个表（商品表、标签表、关联表）就能解决，我这个情况有些复杂，烦请各位知友帮我出出主意
简单介绍下背景，项目是一个第三方展览平台，就是本身不做展览，但负责联通展品、参展人、品牌方、展馆、展览会的这么一个平台，类似中介这样的。参展人或品牌方可以在上面提交自己的展品；有空余场地的人也可以在上面出租自己的场地作为展馆；然后就凑在一起举办展览会。也许我这么说有些莫名其妙，大家不要在意，有协议在身我也不好再细说下去了。
按照目前的需求，上传展品时允许自定义标签，不限数量。参展人和品牌方本身不带标签功能，而是通过“参展人（品牌方）-展品-标签”的方式关联，也就是说参展人的标签取决于他上传的所有展品的标签，品牌方同理。
而展览会本身也不带标签功能，通过“展览会-参展人-展品-标签”的方式关联。展览会有开始时间和结束时间两个字段，超过结束时间则视为展览结束。
问题来了，需求是在展览会列表中，根据标签筛选；而且未参展的标签不显示。
我顿时就懵逼了，按照这个需求，我得先找出所有正在展出的展览会（即已开始且未结束）的参展人或品牌方，然后查出他们所有的展品，然后查出这些展品所有的标签， 然后去除重复的，最后显示。这在未来数据量大了之后将会多么恐怖
我不知道是这个需求本身就不合理，还是说其实有很好的解决办法但我想不到。请各位知友不吝赐教
补充一下，由于对方的一些限制，无法使用诸如redi、memcache、mongodb之类的，只能用mysql
这样的需求用关系数据库实现再合适不过了。
根据你的描述，参见如下数据模型：
根据Tag查询Exhibition:
<code>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
)</code>我对具体需求不太了解，所以你需要根据具体情况设计数据模型。
在逻辑设计的阶段，不要考虑物理实现，数据量等问题，而是要忠于需求，设计出符合逻辑的逻辑数据模型。
在物理实现时，根据需求建索引，甚至分表，等等。
不要过早优化。
以下是个人观点：
慎用人工Id （Surrogate Key）
如果每个表都用一个人工Id，很难分析出符合逻辑的数据模型，数据完整性也得不到保证，而且一个查询往往需要很多JOIN。
数据量
关系数据库的处理能力是很强的,对于几百万级别的表，只要索引设好了，返回相对少量的数据是很快的。如果需要返回的数据量也大，那你不管怎么设计都需要花费很多时间。不要把你的项目想象成google或者亚马逊，那样的话大部分团队根本没时间，也没能力开发出来。即使项目真的很成功，到时再重构也来得及。把经典的关系数据库学好了，足够应付大部分项目。
