http://www.pui.ch/phred/archives/2005/04/tags-database-schemas.html

Hope this helps; it may confirm some of your decisions.

I have a media library system that I wrote which uses tags as opposed to directories to catagorize the files. I don’t have any feature to search across multiple tags as I just don’t see it being necessary for what I want to do. I DO however have a feature to search for untagged items, which is close to the same thing and I think the query will scale alright…

select b.*
from
bookmark b
inner join bookmark_tag using(bookmark_id)
inner join tag using(tag_id)
where
tag.tag in (’library’, ‘language:php’, ‘provides:ajax’)
group by
b.bookmark_id
having
count(tag.tag) = 3

The variables will of course be the tag list (where clause) and the count number.

Problem is this won’t handle any kind of ‘OR’ filter…

[offtopic]
I wrote the backend of the media library script I wrote utilizing ajax. Your site helped quite bit in that endeavor, thanks.
[/offtopic]

I also just thought of the mysql set datatype (http://dev.mysql.com/doc/mysql/en/set.html) its horrible mysql specific and has a limit of 64 items which makes it worthless for tagging, but maybe something along the same concept (really just a bitmap) might be the solution, if you can think of a way to make it scale.

I wonder what people like del.ico.us do, maybe store the tags all in one text field and mysql’s FIELD function. Anyhow it sounds like a hard problem i’m glad im not up to your level of tagging.

* One crazy select with a GROUP and HAVING clause. This worked, but was pretty slow when searching with more than one keyword.
* A query with nested subselects for each keyword. This can be pretty slow with two keywords that have a large set, but small intersection. One way to speed it up is to do a count on each tag and then order it so that the tag with the fewest bookmarks is nested the deepest (or was it first?).
* I’ve also been playing around with mysql’s fulltext search. In your case, add an indexed fulltext column to the bookmarks table and then query against it. While this was pretty fast, fulltext search really wasn’t a good match.

So far I’m sticking with number 2, thought I’m not really happy with the performance for edge cases. In my case the database has 1 million records in the equivalent of your bookmark table, 9 million in the join table, and about 80K in the tag table. For the most part results are quick (1-3) seconds, but other searches take much longer.

Like you, I can’t help but think there’s a better way to do it.