database - 用于多实体高性能标记的数据库

Question

我正在为社交应用设计数据库，并试图确定我的方法是否 1) 会表现良好，以及 2) 是否正确规范化？

我对标签查询性能和数据库设计的研究得出结论，具有全文索引搜索的单个标签表可产生最佳性能。

请参阅:http://tagging.pui.ch/post/37027746608/tagsystems-performance-tests

我知道我可以(并且应该从纯标准化的角度来看)将标签放在一个单独的表中，每个标签都有一个键，但是随着数据库变大(根据链接的文章)，性能会受到影响。标签搜索是我的应用程序的关键组成部分，必须表现良好。

下面的结构说明了我设计的一种使用桥接元数据表的基本方法，我希望使用这个单一的表来桥接更多的“对象表”，但我只提供了几个来说明这个想法:

用户表:UserID PK、UserName等

博客表:BlogID PK、UserID FK、BlogTxt 等

照片表:PhotoID PK、UserID FK、PhotoPath 等

元数据表:MetadataID PK、UserID FK、ObjectTable(帖子或博客)、ObjectID FK(PostID 或 BlogID)、标签(tag1、tag2、tag3)

除了上述问题，我也很想知道是否有更好的选择。我是数据库设计的新手，所以请原谅我对正确执行此操作的任何严重无知。非常感谢。

Answer 1

My research on tag query performance and db design concluded that a single tags table with full text index search yields the best performance.

这实际上是不正确的...

您可以获得的最佳性能是切换到具有数组类型和位图索引扫描的数据库引擎，在 int[] array 中维护标签的聚合。使用触发器的列，并在其上添加适当的索引(gin、gist、rtree)。

这允许编写查询(下面的 Postgres 语法)，例如:

create index on posts using gin (tags);

-- bitmap AND/OR index scan on posts
-- has 1 or 2 or 3 or any of 4, 5, 6 without 7 or 8
select *
from posts
where tags && array[1,2,3]
or tags && array[4,5,6] and not tags && array[7,8]

以上内容将消除您可以想到的使用 MySQL 的任何潜在优化。