Comments on: Adding tagging to my php CMS

Question: Adding tagging to my php CMS

yeahyeahyeahwhoo — Wed, 22 Mar 2006 13:51:49 -0800

Whats the best way to setup and implement a tagging/folksonomy system into a php content management system from scratch?

I use a custom php based content management system at my work and i'm wondering what what the best way to set up a tagging/folksonomy type system like the ones you see here and delisous, etc. i'm building it into my system by hand, but i'd really like some advice on where to start, such as table structure, useful functions, etc.

I appreciate any help, this has been a difficult thing to google for.

By: mathowie

mathowie — Wed, 22 Mar 2006 14:08:49 -0800

It's super easy actually.

You have a tags table in your db, and it should have fields for tag_name and parent_id at the very least. The parent_id corresponds to whatever you are associating tags with, be they single pages, blog posts, whatever.

Then you create a form to add tags however you want (flickr style, or make them like yahoo's myweb) and associate them with your parent_ids when adding new content or editing old content.

Finally, you just display them on the appropriate page where parent_id = foo and you grab all tag_name items with parent_id = foo.

By: jellicle

jellicle — Wed, 22 Mar 2006 14:36:55 -0800

Here's your answer.

There are some tricky bits because of the limitations of SQL. Tradeoffs, if you will. If you want to allow infinite tags per piece of content, you have to set up the database like so. If you can limit the number of tags, you can set it up like so. If the query has to be fast, you have to set up the database like so, if it doesn't, you can set it up like so. And so on.

By: Rhomboid

Rhomboid — Wed, 22 Mar 2006 17:00:28 -0800

Yikes. The "MySQLicious" schema in that link is just horrid. By all means do not pick that one. The "Toxi" one (which displays actual knowledge of how SQL is supposed to work) is your best bet. Don't let the fact that whoever wrote that summary is apparently database-clueless ("I couldn't come up with an easy MySQL-query.." --WTF?) cloud your judgement.

By: beerbajay

beerbajay — Wed, 22 Mar 2006 18:38:00 -0800

Ditto Rhomboid. That person is an idiot; don't listen to them. There's no good reason to cram all the tags in one field. Parse the user input, ffs.

You shouldn't need to fulltext search the tags unless you are beholden to the whims of ridiculous people like librarians.

By: philipp.keller

philipp.keller — Wed, 22 Mar 2006 23:30:12 -0800

The person who wrote that article is speaking.. :-)

It surely depends on what you are trying to do. If you are are in a hurry and you are sure you'll never get more than 1000 entries then I still think you should take the most simple "MySQLicious" approach. That is completely denormalized and yeah, not optimized by any mean (as Rhomboid said), it's the "quick and dirty" solution. You won't have many options. Building a tag cloud with this solution is quite difficult as you don't see how often a tag is used.

We recently added tags to our CMS and we took the "toxi" solution, this is 3NF, the way you learnt it in school. You can have multiword tags and everything you like. You have to deal with tag orphans. Overall you have to invest some time and thoughts into implementing your tag schema this way but it's worth it.

If you're building middle-scale application (up to 1 million items), performance wise you best pick the toxi or the mysqlicious solution with MySQL fulltext search.
If you want to build a bigger app, then you have to mix in non-RDBMS-systems like Lucene.

Yes, speaking about minus-queries (like "I want to see all posts tagged 'fruit' and 'vegetable' but not 'apple'") I wrote "I couldn't cdome up with an easy MySQL-query": I still cannot think of an easy way to solve this. I would have to do two separate queries one for the "wanted" tags and one for the "unwanted" tags and then would have to join these together. This would be very slow I guess.
Can you come up with a good query?

By: Rhomboid

Rhomboid — Thu, 23 Mar 2006 00:03:52 -0800

Yes, speaking about minus-queries (like "I want to see all posts tagged 'fruit' and 'vegetable' but not 'apple'") I wrote "I couldn't cdome up with an easy MySQL-query": I still cannot think of an easy way to solve this. I would have to do two separate queries one for the "wanted" tags and one for the "unwanted" tags and then would have to join these together. This would be very slow I guess.
Can you come up with a good query?

How about:

SELECT b.*
FROM tagmap bt, bookmark b, tag t
WHERE bt.tag_id = t.tag_id
AND (t.name IN ('fruit', 'vegetable'))
AND b.id = bt.bookmark_id
AND t.tag_id NOT IN (SELECT tag_id FROM tag WHERE name = 'apple')
GROUP BY b.id
HAVING COUNT( b.id )=2

MySQL has had subqueries since 4.1, released 2003-04-09 -- nearly three years ago! The people that refuse to use "real" database features like subqueries in MySQL because they're stuck in the stone age of 3.whatever are the same people that give MySQL a bad name for being a toy database.

By: philipp.keller

philipp.keller — Thu, 23 Mar 2006 00:08:21 -0800

Rhomboid: Thanks! I confess I'm stuck in the stone age of 3.whatever and therefore confess that I'm "database-clueless" :-)
I'll add this to my article if you don't mind?

By: Rhomboid

Rhomboid — Thu, 23 Mar 2006 00:14:10 -0800

Hum, that is bogus... I spoke too soon.

By: Rhomboid

Rhomboid — Thu, 23 Mar 2006 00:24:36 -0800

I think this is closer to what you want, although I didn't test it:

SELECT b.*
FROM bookmark b, tagmap bt, tag t
WHERE b.id = bt.bookmark_id AND bt.tag_id = t.tag_id
AND (t.name IN ('fruit', 'vegetable'))
AND b.id NOT IN (SELECT id FROM bookmark b, tagmap bt, tag t
                 WHERE b.id = bt.bookmark_id AND bt.tag_id = t.tag_id AND t.name = 'apple')
GROUP BY b.id
HAVING COUNT( b.id )=2

By: Rhomboid

Rhomboid — Thu, 23 Mar 2006 00:26:48 -0800

Might have to use "b.id" instead of just "id" in the SELECT in the subquery.

By: philipp.keller

philipp.keller — Thu, 23 Mar 2006 00:36:20 -0800

Yeah, this looks like it would work. I'll test it and then will add this to the article. Thanks for helping out!

By: yeahyeahyeahwhoo

yeahyeahyeahwhoo — Thu, 23 Mar 2006 05:51:57 -0800

i thought that article was awesome for someone like me that wasnt shat out of the womb knowing all there is to know about database schemas, thats for the help folks.

what i had drawn up previously was closer to the mysqlicious deal but i can really see the sexiness in the 3 tables. performance isnt a huge issue but i'd rather tackle it now.