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

Question

对于标签数据库模式的 Toxi 解决方案，我有点头疼。我正在开发一个用户可以提交项目的系统，这些项目可以有与之关联的标签。在阅读了 tagschemas 之后，我发现 Toxi 解决方案最适合我的需求。但是，我不完全确定我的计划是否正确，所以我想听听您对此的意见。

我将拥有三个数据库。
items 包含item_id 和其他
tagmap 使用 item_id 和 tag_id 作为外键
tags 包含tag_id 和tag_text

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

1. 将提交的标签排序到数组中
2. 对于数组中的每个标签：
   1. 从 tag_text 与当前标签匹配的标签中获取 tag_id
   2. 如果返回 0 行：
      1. 在标签表中添加标签
      2. 获取tag_id
   3. 将 item_id 和 tag_id 添加到 tagmap 中
3. 完成（给用户一个好的，等等）

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

至于编辑标签，我已经想到了以下过程，虽然我认为还有更好的方法我还没有找到。

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

我对那里的第 3 点有点怀疑。有没有办法让我检查是否有任何标签已被删除，这样我就可以有选择地删除标签，而不仅仅是删除并重新添加它们？ 并且只是为了确定：当删除 tagmap 行时，相关项不会被删除，因为它指向一个外键而不是一个外键，对吧？

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

回想起来，那是相当大量的文字。 Welp，宁可太详细也不要遗漏信息，宁可问太多问题，学很多新东西，也不要问太少。 好机会我今天花了太多时间研究这个，明天就会更有意义。

提前致谢！

Answer 1

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

现在到问题本身......

我将拥有三个数据库。

不，您将有 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');

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

这假设所有必需的标签都已经在tags 中。假设 tag.tag_id 是自动递增的，您可以执行以下操作来确保它们是：

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

这意味着我们最终会在标签映射中为每个项目的每个标签创建一个条目。这似乎是正确的，但我不禁想到有更好的方法来做到这一点，然后在那里有大量的条目......

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

至于编辑标签……

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

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

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 Fiddle 中玩所有这些。

为了确定：当删除 tagmap 行时，相关项不会被删除，因为它指向一个外键而不是一个外键，对吧？

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

顺便说一句，您使用此架构是因为您希望在 tags（tag_text 旁边）中添加其他字段，对吧？如果你这样做了，不要因为所有连接都消失而丢失这些额外的数据。

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

这不仅可以简化 SQL，还可以提供更好的clustering。

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

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

在你决定做这样的事情之前进行测量。上面提到的我的 SQL Fiddle 在tagmap PK 中使用了非常慎重的字段顺序，因此数据以一种对这种计数非常友好的方式进行聚类（记住：InnoDB tables are clustered）。在这成为问题之前，您必须拥有真正大量的项目（或需要异常高的性能）。

无论如何，衡量真实的数据量！