How to handle multiple value selections in PHP and MySQL - php

Question

I recently took an online PHP / MySQL course and as a way of practicing I make a stock keeping site for a paint shop.
We have a paint table:
paintID: INT, AI
paintType: varchar (e.g. metal, primer, water-based, etc.)
paintPrice: INT (e.g. 10, 15, 20)
paintColor: ???
A colors table:
colorID: INT, AI
colorName: varchar (e.g. blue, red, white, transparent, etc.)
Every paint product comes in one or more colors. So I thought of making a section within the product.php page offering all the colors as checkboxes. While this is simple enough when creating new products,
how can I store the selected colors via PHP in the MySQL database once user presses submit (and what type to give to the paintColor column)
how can I retrieve/show all the possible colors with the chosen ones selected once in 'read-only' or 'update' mode of the product page

Answer 1

The relationship between a Paint and a Color is Many - to - Many.
Conceptually you can have a M <-> M relationship between two entities, but in a concrete implementation, you need a "resolver" table between the two entities. I would probably call this table "paintColor"
It would have something like this in it:
paintColor
----------
paintColorID
paintID (FK to paint)
colorID (FK to color)
As you should be able to discern, this allows you to associate any number of separate color values with a specific paint. I personally don't know if this is actually a feasible design, due to questions regarding whether a specific instance of a paint/color combination doesn't need to have other attributes such that your original design with ColorID as a foreign key in Paint isn't actually what you want.
For example, if a Paint can have different prices for "Gold" vs. "Black" then you have an issue with your current model, unless you attach pricing to paintColor rather than paint. Any data model with a degree of sophistication will have many of these tradeoffs incorporated, and it may not be obvious as to what the reasoning was behind the design.
In your simple model there are probably other foreign key relationships you would want in an actual paint store application, like manufacturer. PaintType should be in a table, and not as a varchar.
MySQL actually has a special datatype that essentially allows you to embed a many to many in one column. It's called an ENUM. If you want to use it for this app, it's not the worse decision you could make, so long as you keep in mind that an ENUM violates the basic rules that all relational databases were supposed to support. For your simple application, it allows you to make a "have your cake and eat it too" which works fine in a simple application. Again, if a paint can have a different price point for 2 different colors that are otherwise the same paint, then you have a problem.
For this reason, often Many to many relationships are more appropriate, and in the way you described your app and the interface you expect, the solution is a Many to many. It's important after you make that choice that you start to learn the implications of that choice for your application.
I usually advise people to think about what the choice entails: If it's a 1-1 relationship then Entity A can have one and only one property B.

Answer 2

If you fill the colors table with preset colors yourself, you can allow the user to select a color from your predefined entries and you store the colorID from the colors table in the the row as foreign key using color in the paint table when you store the user's entry and to retrieve do a left out join on the color table where the ID in the paint row with ID on the row in the color table. The statement would look like...
Junction table
CREATE TABLE juct_paint_color (
paint_key int not null,
color_key int not null,
FOREIGN KEY(paint_key) references paint(paintID),
FOREIGN KEY(color_key) references color(colorID)
)
New insert statement for junction table after you insert the new paint.
INSERT INTO juct_paint_color(paint_key, color_key) VALUES(?, ?)
NEW select statement, you can keep the select the paint however you were doing so before but the two get the color simply used the paintID column from the paint table like so.
SELECT t2.* FROM juct_paint_color t1
LEFT OUTER JOIN color t2
ON t2.colorID = t1.color_key WHERE t1.paint_key = ?;
you could use a transaction or stored procedure in you database to ensure that a new paint row is never inserted without a proper entry to the junction_table, but if you constrict the user input it probably won't be necessary.