Two Tables With Same Name Needed - What's wrong with this design?

I'm working on two website projects at once. However, the two websites will be so interconnected that they are sharing the same database.

For the first site, let's just call it a car site, I created a table called "tag" that holds tags/labels/categories that get assigned to entries, much like the tag system here on SO. Now I need another table to hold tags for a different type of entry, unrelated to the cars. For the sake of example, let's just say I want to tag clothing.

I already have a table called car_tag that joins cars with tags.

Should I be storing tags for the two different types of "products" in the same table? I'm using the nested set model and I think this could get quite confusing and the day something would get corrupted on the entries the website users would be extremely confused.

Any suggestions? Tag1 and Tag2? I think I might need even more tags later on for a different but related project on t开发者_如何学Che same website.

---

As long as the tags serve the same semantic purpose, then I don't see an issue with combining them into one table. You should consider adding a TagType/TagTypeId field to explicitly state which type of tag you're storing (cars, unnamed entity).

Just remember that you have the option of splitting them out to different tables if you need to for performance reasons.

---

Agree with - they should be perfectly happy to sit in the same table.

In fact, if they represent the same object / concept it would be incorrect to put them in separate tables.

I would also argue that you don't need to 'split' the tags in any way. If there are red cars and red clothes, then what would be the harm if they both link to the same red tag? You may someday need to find everything that has a red tag, after all. No harm at all.