請問關於商品標籤的資料庫設計及多層關聯邏輯？

普通的一個商品對應多個標籤的設計只需要3個表（商品表、標籤表、關聯表）就能解決，我這個情況有些複雜，煩請各位知友幫我出出主意

簡單介紹下背景，項目是一個第三方展覽平台，就是本身不做展覽，但負責聯通展品、參展人、品牌方、展館、展覽會的這麼一個平台，類似中介這樣的。參展人或品牌方可以在上面提交自己的展品；有空餘場地的人也可以在上面出租自己的場地作為展館；然後就湊在一起舉辦展覽會。也許我這麼說有些莫名其妙，大家不要在意，有協議在身我也不好再細說下去了。

按照目前的需求，上傳展品時允許自訂標籤，不限數量。參展人和品牌方本身不帶標籤功能，而是通過“參展人（品牌方）-展品-標籤”的方式關聯，也就是說參展人的標籤取決於他上傳的所有展品的標籤，品牌方同理。
而展覽會本身也不帶標籤功能，通過“展覽會-參展人-展品-標籤”的方式關聯。展覽會有開始時間和結束時間兩個欄位，超過結束時間則視為展覽結束。

問題來了，需求是在展覽會列表中，根據標籤篩選；而且未參展的標籤不顯示。

我頓時就懵逼了，按照這個需求，我得先找出所有正在展出的展覽會（即已開始且未結束）的參展人或品牌方，然後查出他們所有的展品，然後查出這些展品所有的標籤， 然後去除重複的，最後顯示。這在未來資料量大了之後將會多麼恐怖

我不知道是這個需求本身就不合理，還是說其實有很好的解決辦法但我想不到。請各位知友不吝賜教

補充一下，由於對方的一些限制，無法使用諸如redi、memcache、mongodb之類的，只能用mysql

回複內容：

普通的一個商品對應多個標籤的設計只需要3個表（商品表、標籤表、關聯表）就能解決，我這個情況有些複雜，煩請各位知友幫我出出主意

簡單介紹下背景，項目是一個第三方展覽平台，就是本身不做展覽，但負責聯通展品、參展人、品牌方、展館、展覽會的這麼一個平台，類似中介這樣的。參展人或品牌方可以在上面提交自己的展品；有空餘場地的人也可以在上面出租自己的場地作為展館；然後就湊在一起舉辦展覽會。也許我這麼說有些莫名其妙，大家不要在意，有協議在身我也不好再細說下去了。

按照目前的需求，上傳展品時允許自訂標籤，不限數量。參展人和品牌方本身不帶標籤功能，而是通過“參展人（品牌方）-展品-標籤”的方式關聯，也就是說參展人的標籤取決於他上傳的所有展品的標籤，品牌方同理。
而展覽會本身也不帶標籤功能，通過“展覽會-參展人-展品-標籤”的方式關聯。展覽會有開始時間和結束時間兩個欄位，超過結束時間則視為展覽結束。

問題來了，需求是在展覽會列表中，根據標籤篩選；而且未參展的標籤不顯示。

我頓時就懵逼了，按照這個需求，我得先找出所有正在展出的展覽會（即已開始且未結束）的參展人或品牌方，然後查出他們所有的展品，然後查出這些展品所有的標籤， 然後去除重複的，最後顯示。這在未來資料量大了之後將會多麼恐怖

我不知道是這個需求本身就不合理，還是說其實有很好的解決辦法但我想不到。請各位知友不吝賜教

補充一下，由於對方的一些限制，無法使用諸如redi、memcache、mongodb之類的，只能用mysql

這樣的需求用關聯式資料庫實現再合適不過了。
根據你的描述，參見如下資料模型：

根據Tag查詢Exhibition:

SELECT e.GalleryId, e.StartTime, e.EndTimeFROM Exhibition eWHERE 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或者亞馬遜，那樣的話大部分團隊根本沒時間，也沒能力開發出來。即使項目真的很成功，到時再重構也來得及。把經典的關聯式資料庫學好了，足夠應付大部分項目。

