"Taxonomy won't work well with 1000 tags". "Taxonomy needs too much work to support folksonomy modules.". "Use system vocabs" I looked at this page /admin/taxonomy and some of the Taxo edit controls and couldn't see it working with very large numbers of terms. I think *all* the user interface for a tag vocabulary would need reworking. So it's hard to see what actually gets reused. The form control for use on nodes is going to be different so preview form would need a hook. Although some Taxo functions for saving and loading could be re-used, the output from a free form tag entry will need converting before it fits into the Taxo scheme. So yes, it would be possible to use the vocabulary and vocabulary_node_types tables (at least I haven't yet needed to extend them) but taxonomy admin couldn't show them usefully and almost none of the vocab manipulation code can be used as is. So what's the point? However, Moshe's last post convinces me I need to go and look at 4.6 forum and prove to myself again that Realm can't use the vocabulary table and there's nothing in taxonomy that can be used as is. Data model. I don't believe that users own their tags. I think they only use tags on specific data. So "My Tags" means "The Tags I've used". In which case either node_tag has a uid field or we derive it from node.author. There's a fundamental choice that affects everything else. And it all depends on if you think a tag exists independent of the nodes or other objects it's attached to. Or that tags only exist 1) Independent tag Realm table; rid, name Realm_type table; rid, type Tag table; tid, rid, name optionally add cached data like count node_tag table; nid, tid Optionally rid to make queries faster and reduce joins. 2) Dependent tags Realm table; rid, name Realm_type table; rid, type node_tag table; nid, rid, name 1) Is more normalised. It will make adding tag_tag synonym and related tables easier to build later. It makes admin editing a tag easier. It needs more joins. The saving process may get slow as each tag has to be found or added before the node_tag link can be created. In 2) most of the queries are easier, faster and use less joins. The downside is admin editing a tag is a little harder. Arguably there's data duplication; potentially X*Y*Z entries in node_tag where X is nodes,Y is tags per node, Z is average tag length. In practice that's just not an issue. Note: All the data model stuff assumes a single link between nodes and tags. If you want to do users as well I think there has to be a second link table user_tag. Or maybe table_tag_type; id,tid,type but then the joins are going to get very nasty. -- Julian Bond Email&MSM: julian.bond at voidstar.com Webmaster: http://www.ecademy.com/ Personal WebLog: http://www.voidstar.com/ M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433 S: callto://julian.bond/