Database design for products with multiple categories and multiple sub-features

Question

Suppose you are designing a searchable database for a webstore, and have a situation like the following:

---

Each product will have multiple, differen

Answer 1

Just have the database say what's so.

yn = yes,no
age_range = 0-4,4-6,6-12,...
use = Fine-Drawing,Canoeing,...
surface_group = All,PaperOrSkin,PaperOrWall,...
PRODUCT(p,n) -- product [p] is named [n]
TOY(p,AgeGroup,Toxic,ChristmasSpecial,...)
    -- [p] is a toy for age range [AgeGroup] and whether it's toxic is [Toxic] and whether it's on Christmas special is [ChristmasSpecial] and ...
SCHOOL-STATIONERY(p,BulkAvailability,...)
    -- [p] is school stationery and its bulk availability is [BulkAvailability] and ...
ART-ACCESSORY(p,Use,CompatibleSurface,...)
    -- [p] is an art accessory with use [u] and is compatible with surfaces in surface group [CompatibleSurface] and ...

An SQL query combines conditions and tables. The meaning of the query is combined from the conditions and the table meanings given above.

See this stackoverflow post from today or zillions of others on EAV and OTLT. Or this. Also, just learn about database design. Maybe starting here.

Notice things are simpler if yes/no choices are separated:

TOY(p,AgeGroup,...) -- [p] is a toy for age range [AgeGroup] and ...
TOY-TOXIC(p) -- toy [p] is toxic
TOY-XMAS-SPECIAL(p) -- toy [p] is on Christmas special
SCHOOL-STATIONERY(p,...) -- [p] is school stationery and ...
SCHOOL-STATIONERY-BULK-AVAILABLE(p) -- school stationery [p] is available in bulk

Probably you also want to sometimes not have labels for groups of things but simply state about the things or the first and last things in a range:

age = 0,1,2,...
surface = Paper,Skin,Wall,...
TOY(p,...) -- [p] is a toy and ...
TOY(p,MinAge,MaxAge) -- [p] is a toy with age minimum [MinAge] and maximum [MaxAge]
ART-ACCESSORY(p,Use,...) -- [p] is an art accessory with use [u] and ...
ART-ACCESSORY-COMPATIBLE-SURFACE(p,CompatibleSurface) -- accessory [p] is compatible with surface [CompatibleSurface]

You can always change the currently-hardwired info (type sets and type, column and table names). You can always write generic queries that don't even know what is hardwired because all the hardwired names are values in the tables constituting DBMS metadata.