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!
-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
On Thu, Jan 20, 2011 at 2:40 PM, Jerry Schwartz je...@gii.co.jp wrote:
-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
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
6 matches
Mail list logo
