是否考虑增加 tag 表与 memo 做关联替代目前正则解析的方式

[zy9306]

Is your feature request related to a problem?

目前依靠正则解析 memo 中的 tag，后期需要对 tag 做些删改操作都不是太方便，单独有一张 tag 表后期能解决很多问题 （虽然这种量级没必要考虑性能问题，但单独抽张表比目前遍历所有 memos 拿到 tag 效率要高得多）

Describe the solution you'd like

增加 tag 表

Additional context

No response

[zy9306]

存量数据的兼容问题可以提供一个脚本升级时批量处理一遍

[boojack]

@zy9306 暂不考虑，因为目前 tag 是存储在 memo.content，可以直接从里面获取出来，没必要再新建表来存储。

还有一个更为可行的方式是加一个 memo-shortcut table，与现在的 memo-resource 类似，可以用于实现类似于 tag 的效果，WDYT？

[zy9306]

@zy9306 暂不考虑，因为目前 tag 是存储在 memo.content，可以直接从里面获取出来，没必要再新建表来存储。

还有一个更为可行的方式是加一个 memo-shortcut table，与现在的 memo-resource 类似，可以用于实现类似于 tag 的效果，WDYT？

@boojack 主要是想解决 tag 更新删除的问题，现在想动 tag 就需要遍历所有 content，把相关的修改一遍。元数据与内容解耦应该是比较通用的做法，tag 应该是一个独立可复用的资源，要考虑的只是关联关系。可能这边设计之初就是把 tag 当作内容的一部分，这个我也并不是不能想象。

[boojack]

tag 放在内容里是 by design。后续将在后端实现一个 markdown parser，可以来做 tag 的更新和删除。

[zy9306]

@boojack 虽然这种量级不应该较真，不过我觉得这不是一个好的设计，后面有时间我再自己改下看看，先关闭了

[boojack]

新增了 tag table: https://github.com/usememos/memos/pull/811

[NICEXAI]

我们之前有一个类似memos的项目，在对标签的处理上，我们的方案是：

我们有一张Tag表，Tag表内的每条Tag数据都会有一个计数器，计数器记录了当前这个Tag被其它资源（笔记、图片、链接、文件等资源）引用次数。资源标签更新时会同步更新计数器，计数器数值为零时（即未被任何资源引用）系统会自动删除这个标签。另外为了便于快速进行检索，还会有一张关系表，记录了所有标签和资源的关联关系。

标签的提取上由于我们是自己基于slate开发的编辑器，每个标签都是一个Node节点，服务端只需要便利一遍节点数据就可以筛选出所有标签。