Predefined rows conflicting with user entered rows

Question

Is there a pattern to deal with a set of predefined rows in one or more tables that can also have user-defined rows inserted in them?

I could want to distribute an application with a table called Colors where I defined some colors that are, for example, used in the application's GUI. I might use one column for a numerical primary key, one for the name and three other columns for R,G,B values. I would put an unique constraint on the name column and one for the three R,G,B columns. The contents of this table are intended to be available to the user so that when he needs to specify a color he can choose one from the table. However it makes sense to allow the user to add his own colors to the table.

Issues however could arise if the user wants to:

• define a color whose R,G,B value are already used in a predefined color
• use a name that is already in use by a predefined color
• hide predefined colors he's not interested into

I need to have some predefined, read-only, rows on which the application can rely but at the same time I don't want to impose anything on the user while providing him with the opportunity to use some of the predefined rows if he chooses to.

I thought of separate tables or a single table with extra columns that specify if the row is predefined, hidden by the user and so on. However I can see flaws in both approaches.

Answer 1

Reflection, not an answer.

---

---

define a color whose R,G,B value are already used in a predefined color

I cannot find a reason to forbid for a user to create his own color name for some color. So (R,G,B) must NOT be unique.

use a name that is already in use by a predefined color

I cannot find a reason to forbid for a user to create his own color for some color name. So (color_name) must NOT be unique.

---

As I see there is to exist additional field user, which allows each user to create his own colors collection. user field is nullable, Null value means this is a color available to all users (predefined colors, for example). But:

hide predefined colors he's not interested into

means that there must be another method - while creating user you must copy all predefined colors to him personally. To mark any color as not interesting for current user you may add additional field or use any another method (for example, add some char - asterisk or minus sign, etc. - in front of color's name which is not allowed as first char for active color name).

Alternatively you can create a table with base colors and a table with color aliases personal for each user. Each new color created by some user is inserted in both tables whereas any existing color is inserted in second table only.