A tradeoff in defining database schemas

Here are some decisions of a sort that comes up frequently: You have a hats table in your database with uuid, hat_type (e.g., fedora or trilby), size, and dress_code_level columns. Now you need to describe fascinators in your database also. They also have sizes and dress code levels, but also attachment_type, attachment_position, and has_veil. Do you (i) create a separate fascinators table or (ii) add some columns to your hats table, rename it to millinery, and accept that fields like attachment_type can be null in some cases but not others? You need to store user settings. Right now the only settings are a preferred time zone and a preferred theme (dark or light mode), but some day you'll probably need more. Do you (i) have columns for preferred_time_zone and preferred_theme, and accept that you'll need to change the schema later to support more settings, or (ii) put settings in a settings JSON1 column? You are collecting data about hat interactions. Sometimes people tip their hats,…