Вопрос по внешним ключам, целостности данных и пр

Все добрый день.
Такая ситуация.
Есть таблица users, в ней login,email, но главное айдишник на другую таблицу.
Например color_eye_id(цвет глаз пользователя)
Ну и соответственно таблица eye_color(id,name) в которой хранятся цвета глаз

Это поле необязательно для заполнения. Т.е. в настройках пользователя, в форме у тега select по умолчанию висит значение "не выбрано".
Я хочу сделать чтобы нельзя было добавить в users что-то левое, это решается ограничением по внешнему ключу.
Если в родительской таблице придется поменять например "серый" на "голубой" при том что "серый" везде используется, это тоже можно сделать с помощью update cascade.
Но если я хочу удалить запись из родительской таблицы, она уже используется в дочерней, я конечно могу сделать delete set null во внешнем ключе, но тогда в таблице пользователя будет висеть null, таких нулов будет много - это не есть гуд. Если сделать delete cascade то запись пользователя вообще уничтожится. Хотелось бы чтобы пользователь допустим сделал себе цвет глаз "красный", а потом разработчики из родительской таблицы удалили этот цвет и у пользователя снова получалось "не выбрано". как это сделать без манипуляций с php, добиться такой гибкости и одновременно целостности?
Пробовал так же через ENUM сделать,т.е. без родительской таблицы уже. Вбивал все цвета глаз туда значениями. Но при удалении значение из enum, в users в этом поле просто пустота получается, хотя ENUM'у я задавал дефолтное значение.

Может я где то ошибаюсь. Прошу помощи
Спасибо заранее за помощь

NULL и есть лаконичное определение "не выбрано".
Не выбрано - это не цвет глаз, это не выбрано. И в цветах глаз его и не должно быть.

-----
PostgreSQL DBA

Просто null занимает больше места. хотелось бы 0 хотя бы поставить, но такой фишки нет. тем более у меня на это поле стоит not null.

или можно сделать чтобы у этого поля был дефаулт 0 к примеру, not null убрать и тогда после удаления вместо null ноль будет?

это нормально ? не изобретение велика?

На целый 1 бит больше. Ну-ну. И где?! В таблице юзеров. 1 бит.
0 - это тоже значение и попадает в полной мере под constraint.
Вы занимаетесь преждевременной оптимизацией.

-----
PostgreSQL DBA

Провел эксперимент уже. все равно запиcывается null а не default значение
(Добавление)

Возможно вы правы.
(Добавление)
Т.е. вы предлагаете не парится и null писать?)
Просто не помню где но прочитал что null не желательны в бд

null - это нормально там, где они уместны. Иначе null'ов бы не было вообще реализовано.
Но как пихают булево значение в полновесный int, так и null'ы не в том месте только мешают.

-----
PostgreSQL DBA

А вариант с enum чем плох?