Quote:
Originally Posted by Atli
I should mention that you really shouldn't store more than one piece of data in a single field, like you do with your tag field.
(Check out Database normalization and Table structure for details on that).
Each single piece of data should be placed in it's own field, which in your case, would require a new table to be created.
Consider this table layout. It's not perfect but it's a big improvement:
-
Image
-
----------
-
ImageID Int (PK)
-
ImageName Char(Unique)
-
Etc...
-
----------
-
-
ImageTag
-
----------
-
TagID Int (PK)
-
ImageID Int (FK)(Unique)
-
TagName Char (Unique)
-
----------
-
In the second table the ImageID and TagName fields would share a Unique key, making it impossible to insert the same tag twice for the same image.
This may seem unnecessary extra trouble, but you should always try to normalize your database. It makes it much easier to work with, especially if it ever needs to be extended or altered.
I could go either way, actually. If images had an average of 5 tags, your image table would be five times larger.
when searching, you could always use the "LIKE" clause to search for something like "%:mountain:%", in the tag field.
As for "searching" to eliminate duplicates. The tag field will be an array of only several fields, array searching would be fast.
Just some thoughts, It depends on the use and your particular needs,
Dan