mysql - 基于标签的数据库存储是个好主意吗？

Question

我正在开发一个类似社交网络的软件，其中有一个带有人员表的数据库:

Person
--------
id
firstname
lastname
mail
birthday
[etc.]

现在的问题是我想让用户添加非常详细的信息。例如，这个人有什么纹身、在哪里、大小等等。使用当前的数据库布局，我必须添加另一个纹身表:

Tattoo
--------
id
fk_person
size
position
[etc.]

现在纹身是我想添加的不是唯一的新表，还有其他关于头发、穿孔、音乐品味等的表。

现在回答这个问题:将所有数据存储在单个 Tag 表中不是一个好主意吗:

Tag
--------
id
tag_name
tag_value

在那里我可以添加这样的数据:

1 | tattoo_size | large
2 | tattoo_size | medium
3 | tattoo_size | small
4 | firstname | Peter
5 | nickname | Pete
7 | birthday | 11.11.1999

加上一个n到n表Person到Tag。

id
fk_person
fk_tag

使用这样的数据:

1 | 25 | 1
2 | 25 | 4
3 | 23 | 1

这样，如果两个人有一个大纹身或名字彼得(例如)，并且人们可以有任意数量的纹身，那么就没有多余的信息。

这似乎带来的额外好处是搜索会更容易:您只需在 Tag 表上运行 SELECT 即可关键字。

我正在使用 MySQL 和 PHP，以防万一。

好主意？坏主意？有更好的主意吗？

谢谢

Answer 1

如果您需要能够查询“所有有纹身和穿孔的人”之类的内容，那么您必须将其构造为人员和标签之间的多对多。您可以将标签命名为标签表中的一列，例如 category='body',name='piercing'，也可以将该信息烘焙到标签本身中，例如body.piercing` if您可以保持命名足够简单，以避免与分隔符发生潜在冲突。

如果你不需要以聚合的方式查询这些东西，只需使用 JSON column并将您的数据存储在那里。您可以非常灵活地组织它，而无需创建大量的表。

这里的风险是创建一个过于通用的结构会给你带来一个非常糟糕的文档存储。如果您要走这条路，请评估类似 MongoDB 的解决方案也是如此。