标签系统：Toxi 解决方案问题

我对标签数据库模式的 Toxi 解决方案感到有点困惑。我正在开发一个系统，用户可以向该系统提交项目，并且这些项目可以具有与其关联的标签。在阅读了 tagchemas 后，我发现 Toxi 解决方案最适合我的需求。但是，我不完全确定我的计划是否正确，所以我想请您对此发表意见。

我将拥有三个数据库。
items含有item_id和别的
tagmap using item_id and tag_id作为外键
tags含有tag_id and tag_text

添加新项目时，我是否可以假设将标签添加到数据库的过程如下？

1. 将提交的标签排序到数组中
2. for every tag in the array:
   1. 从 tag_text 与当前标签匹配的标签中获取 tag_id
   2. if that returns 0 rows:
      1. 将标签添加到标签表
      2. 获取tag_id
   3. 将 item_id 和 tag_id 添加到 tagmap
3. 完成（给用户“好的”等）

这意味着我们最终会在标签映射中为每个项目的每个标签提供一个条目。这似乎是正确的，但我忍不住认为有一个更好的方法来做到这一点，而不是最终在那里有大量的条目......

至于编辑标签，我想出了以下过程，尽管我认为还有更好的方法，但我还没有找到。

1. 使用 item_id 获取标签并插入可编辑字段
2. 用户进行更改。提交时：
3. 从 tagmap 中删除 item_id 与正在编辑的行匹配的行
4. 与上面列出的过程相同

我对第三点有点怀疑。有没有办法让我检查是否有任何标签已被删除，以便我可以有选择地删除标签，而不仅仅是删除并重新添加它们？ 并且可以确定的是：删除标记映射行时，相关项目不会随之删除，因为它指向外键而不是充当外键，对吧？

另外，我可能想跟踪标签的使用次数，但我不想在每次需要显示标签时运行查询来计数。我正在考虑让 cron 作业每小时或每两小时计算一次 tagmap 中每个 tag_id 的实例数量，然后更新标签表中的 tag_use 值。这是正确的方法，还是有更好的方法？

回想起来，这是相当大量的文字。好吧，宁可太详细，也不要缺少信息；宁可问太多问题并学习很多新东西，而不是问太少。 很可能我今天花了太多时间研究这个问题，明天一切都会变得更有意义。

提前致谢！

首先，“毒素”并不是一个标准术语。始终定义您的术语！或者至少提供相关链接。

现在回答问题本身......

我将拥有三个数据库。

不，你会有 3 张桌子。

添加新项目时...

您几乎走在正确的轨道上，只是您可以使用 SQL 基于集合的性质来“合并”其中许多步骤。例如，用标签标记项目 1：'tag1'、'tag2' 和 'tag3' 可以这样完成...

INSERT IGNORE INTO tagmap (item_id, tag_id)
SELECT 1, tag_id FROM tags WHERE tag_text IN ('tag1', 'tag2', 'tag3');

The IGNORE即使项目已经连接到其中一些标签，也允许此操作成功。

这假设所有必需的标签已经存在tags。假设tag.tag_id是自动递增的，你可以这样做来确保它们是：

INSERT IGNORE INTO tags (tag_text) VALUES ('tag1'), ('tag2'), ('tag3');

这意味着我们最终会在标签映射中为每个项目的每个标签提供一个条目。这似乎是正确的，但我忍不住认为有一个更好的方法可以做到这一点，然后在那里结束大量的条目......

没有魔法。如果“项目连接到特定标签”是您想要记录的知识，那么它将have在数据库中有某种物理表示。

至于编辑标签...

您的意思是重新标记项目（而不是修改标签本身）？

要删除列表中没有的所有标签，请执行以下操作：

DELETE FROM tagmap
WHERE
    item_id = 1
    AND tag_id NOT IN (
        SELECT tag_id FROM tags
        WHERE tag_text IN ('tag1', 'tag3')
    );

这将断开该项目与除“tag1”和“tag3”之外的所有标签的连接。依次执行上面的 INSERT 和这个 DELETE 以“覆盖”添加和删除标签。

你可以在SQL小提琴 http://sqlfiddle.com/#!2/49981/3.

并且可以确定的是：删除标记映射行时，相关项目不会随之删除，因为它指向外键而不是充当外键，对吧？

正确的。 FK 的子端点不会触发引用操作（例如 ON DELETE CASCADE），只有父端点会触发。

顺便说一句，您正在使用此架构，因为您需要其他字段tags（旁tag_text）， 正确的？如果这样做，不要仅仅因为所有连接都消失而丢失这些附加数据是理想的行为。

但如果你只是想要tag_text，您可以使用更简单的架构，其中删除所有连接与删除标签本身相同：

这不仅会简化 SQL，还会提供更好的聚类 http://use-the-index-luke.com/sql/clustering.

乍一看，“toxi”可能看起来像是在节省空间，但实际上可能并非如此，因为它需要额外的表和索引（并且标签往往很短）。

另外，我可能想跟踪标签的次数... cron 作业...

在你决定做这样的事情之前先衡量一下。上面提到的 My SQL Fiddle 使用了非常谨慎的字段顺序tagmapPK，因此数据以对这种计数非常友好的方式进行聚类（记住：InnoDB表是集群的 http://www.ovaistariq.net/521/understanding-innodb-clustered-indexes/）。在这成为问题之前，您必须拥有真正大量的物品（或需要异常高的性能）。

任何状况之下，measure基于实际数据量！