Question

我正在设计一个社交应用程序的数据库，我正在尝试确定我的方法是否1）表现良好，2）正确规范化？

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

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

我知道我可以（并且应该从纯粹的规范化角度来看）将标签放在一个单独的表中，每个标签都有一个密钥，但随着db变大，性能会受到影响（根据链接的文章）。标记搜索是我的应用程序的关键组件，必须运行良好。

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

用户表：UserID PK，UserName，Etc

博客表：BlogID PK，UserID FK，BlogTxt等等

照片表：PhotoID PK，UserID FK，PhotoPath等等

元数据表：MetadataID PK，UserID FK，ObjectTable（帖子或博客），ObjectID FK（PostID或BlogID），标签（tag1，tag2，tag3）

除了上述问题，我也有兴趣知道是否有更好的选择。我是数据库设计的新手，所以请原谅任何严重的无知正确的方法。非常感谢。

Answer 1

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

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

您可以获得的最佳性能是切换到具有数组类型和位图索引扫描的数据库引擎，使用触发器在int[] array列中维护标记的聚合，并添加适当的索引（杜松子酒，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可能想到的任何潜在优化。

DB用于多实体高性能标记

1 个答案: