database structure question

Theoretically you can use the old value of the field, split it into array, get form value, split it into array as well and merge those arrays into a single one and write data to the database.
Old: green,red,white

Form: red,blue

New: green,red,white,blue
The major drawback is that user never be able to remove any previously selected items.

Field content will grow and grow and will become unusable after two or three edits.

Theoretically you can use the old value of the field, split it into array, get form value, split it into array as well and merge those arrays into a single one and write data to the database.

Could I use an inner join query?
Persons: Name, address

Issues: Issue

Persons_issues: Name, Address, Issue

It sounds to me like this is not the best implementation of what you are trying to accomplish. If you have a distince set of values that may be chosen from, you are better off creating a child table. This way, you can store none, one, two, five, or however many instances are called for, all attached to the parent record. You will never lose data (unless you specifically delete a row) and can always add to the list. Also, querying/searching/reporting on that attribute will be much easier.
Of course, if you have chosen your design on purpose (i.e. you want to a allow a multi-select list on a single page instead of having the user click on a link to enter more data in the child table/page), I don't have an easy answer for you. You would have to do like Sergey said and split the values up when retrieving AND saving, but to keep the previous ones "marked" you would also need to get involved with JavaScript in a part of the page that I don't think is covered by the events scripting.
As a general rule, per database normalization guidelines, and attribute that can have multiple simultaneous values should be split off into its own table.

It sounds to me like this is not the best implementation of what you are trying to accomplish. If you have a distince set of values that may be chosen from, you are better off creating a child table. This way, you can store none, one, two, five, or however many instances are called for, all attached to the parent record. You will never lose data (unless you specifically delete a row) and can always add to the list. Also, querying/searching/reporting on that attribute will be much easier.

Thanks, Jim. Yes - I am using a child table. I set up a join query to pull the name and address fields from the person table and the issue field from the contact table and use that data to build an issue table. Seems to take care of the problem, although there are some additional clicks.