I'd exclude (1) because new tags require restructuring the table, (2)
and (3) because they break a cardinal rule of design and will be a mess
to query, leaving ...
4) Standard many-many bridge table:
mysql CREATE TABLE items_tags (
id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
itemID int,
I think the canonical way would be to have one table for your items, one table
for your tags, and one table for your tag assignments.
CREATE TABLE items (
item_id INT(11) AUTO-INCREMENT PRIMARY KEY,
item_name VARCHAR(100) NOT NULL KEY,
...
);
CREATE TABLE tags (
tag_id INT(11) AUTO-INCREMENT
On Thu, Jan 20, 2011 at 17:22, Jerry Schwartz je...@gii.co.jp wrote:
I think the canonical way would be to have one table for your items, one table
for your tags, and one table for your tag assignments.
Thank you, I do agree that this is the best way. Other posters seem to
agree as well!
On Thu, Jan 20, 2011 at 17:22, Peter Brawley
peter.braw...@earthlink.net wrote:
I'd exclude (1) because new tags require restructuring the table, (2)
and (3) because they break a cardinal rule of design and will be a mess
to query, leaving ...
4) Standard many-many bridge table:
mysql
-Original Message-
From: Dotan Cohen [mailto:dotanco...@gmail.com]
Sent: Thursday, January 20, 2011 11:25 AM
To: Jerry Schwartz
Cc: mysql.; php-general.
Subject: Re: Organisational question: surely someone has implemented many
Boolean values (tags) and a solution exist
As for setting up
implemented many
Boolean values (tags) and a solution exist
As for setting up a hierarchy, that's trickier. One way to handle that is
to
work like libraries do: 10 is fiction, 10.05 is crime novels, 10.05.07
is
British authors, and so forth. Your `tags` table then looks like
Thanks. I prefer
On Thu, Jan 20, 2011 at 21:40, Jerry Schwartz je...@gii.co.jp wrote:
Thanks. I prefer the parent tag field, though, I feel that it is
more flexible.
[JS] I disagree. The method I proposed can be extended to any depth, and any
leaf or branch can be retrieved with a single query.
I suppose for
[JS] I disagree. The method I proposed can be extended to any depth, and
any
leaf or branch can be retrieved with a single query.
I suppose for retrievals this structure has advantages, but unless
MySQL has a ++ operator (or better yet, one that adds or subtracts 2
from an int) then it looks
