I want to know how I can do this using PHP & MySQL

[nse111]

I want to add tags for a paricular image in my db table.
I want these tags to be stored in one table field.
lets say I entered the following tags for an image:

house
mountainside
lake
greenery

I want these tags to be saved in 1 field named Tags separated by a delimiter.

house:mountainside:lake:greenery

the above is wat shld be stored in my database.

can someone pls tell me how to do this?

like using somethin opposite as the explode() in php.

thanks in advance!!!

[r035198x]

The opposite of explode is implode()

[nse111]

sorry guys i guess thats ike really simple. i used implode

[nse111]

thanks.....................................

[r035198x]

sorry guys i guess thats ike really simple. i used implode

No problem. Just remember to refuse to write any code if you don't have the manual with you.

[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.

[dlite922]

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

[Atli]

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

Using the LIKE clause to search through a large database will most likely take a very long time. Searching through a long string will usually take much longer than simply matching two short strings. Not to mention that searching will render indexes pretty much useless (although I'm not 100% sure on that).

But putting that aside, normalization is less about ease of use and more about maintaining data integrity, reducing the chance of data corruption and other abnormalities, making the database easy to maintain and extend. (among other things.)

Like with the field we are discussing in this thread, it would be extremely easy to corrupt the data or insert duplicates. MySQL considers it a single text field, which leaves it completely in the hands of the API to maintain. The developer of each application that is to use this data must develop their own code to maintain it, which is just silly considering you already have an open connection to a highly refined database engine that specializes in such tasks.

[nse111]

Hmmm really interesting facts guys.. thanks so much I will really consider them! thanks again