I have two tables, images and image_data and here is an example of my image_data table.
image_id | slide_id | language_id | type |
101 | 1 | 1 | CQ |
101 | 2 | NULL | NULL |
56 | 5 | 1 | TN |
56 | NULL | 2 | NULL |
So basically, each image will have different options and I am wondering the best way to implement this.. because I have a feeling I am doing this the wrong way.
With this, I can run a query to use GROUP_CONCAT() to turn values in multiple rows into a single concatenated string.
image_id | slide_id | language_id | type |
101 | 1,2 | 1 | CQ |
56 | 5 | 1,2 | TN |
Which is fine, but the problem with the way I am doing it right now is..it seems like it will be really difficult to update the rows with my backend system.

So with my query, I can determine which ones to check based on the database since I have it all in one row since I concatenated it. But now it’s like.. when I go to click “Save” and update the rows, which one do I update? there can be more than 1 row of the same image id, so how would I update the right one, and so on.
If I checked off another slide for image #101 then I would need to create a new row for it. If after that I wanted to add another language_id to it, then I would need to make sure to not add a new row since one exists with a NULL value, and to just replace the NULL value with the new language id.
It just seems really complicated and there’s so many factors, that using this method is really hard to program.
What would be the best way to do this? Any suggestions are really appreciated.
Thanks!
What you need to do is implement N:M (many-to-many) relationships between your
imagesandslides/languages/typestables so that your design is more normalized (one fact in one place).Think of it this way: one
imagecan have multipleslides, and oneslidemay be an option of multipleimages. — this is a N:M relationship. Same goes for languages and types.What you need to do is get rid of your
image_datatable which houses the options between ALL entities and have three separate cross-reference tables instead. Here’s how you would model it:Base tables:
Cross-Reference tables:
How it would look in ER:
With this type of design, you wouldn’t have to deal with
NULLvalues or figuring out which row to update because you now have just one fact in one place. To get all options, you would still have to doGROUP_CONCAT()like so:Then to update image options, you would use
INSERTandDELETEon the cross-reference tables:Let’s say you wanted to add two languages to an image, you would do
The above query adds languages with id’s of
4and5to the image that has an id of101.To remove options (unchecking on the form) – let’s say you wanted to remove 2 slides from an image
This removes slides with id’s of
3and6from the image that has an id of101.So in your application, you could figure out if you need to do insert/delete queries based on if the user unchecked or checked values in the form for the image.