базы данных Нормализация - поле в зависимости от другого неключевых поля

Question

Ниже приводится часть определения таблицы в SQL Server:

CREATE TABLE User  
[UserId] INT NOT NULL IDENTITY(1,1), 
[EatsFruit] BIT NOT NULL DEFAULT '0', 
[FavoriteFruit] NVARCHAR(50) DEFAULT NULL, 

Как вы можете себе представить, UserId является первичным ключом. Я использовал здесь более простой пример, чтобы объяснить мой вопрос, связанный с полями «фрукты».

Поле EatsFruit будет либо 1, либо 0, в зависимости от того, использует ли пользователь фрукты или нет. Если EatsFruit содержит 1, то поле FavoriteFruit будет включать любимые фрукты пользователя. Если EatsFruit равен 0, то FavoriteFruit не имеет значения, и он должен содержать N/A или некоторую аналогичную ценность.

Мне интересно, какой лучший способ смоделировать это, и нужно ли его нормализовать.

Поскольку поле FavoriteFruit зависит от содержания EatsFruit, следует ли его разделить в другой таблице, содержащей UserId и FavoriteFruit? Это было бы более чистым, потому что запись для определенного пользователя не появлялась бы, если пользователь фактически не ест фрукты (а содержание FavoriteFruit всегда будет актуальным). Однако, поскольку первичный ключ новой таблицы также был бы UserId, не означает ли это, что FavoriteFruit действительно зависит от UserId и не должен был быть отделен от основной таблицы в первую очередь?

Что было бы лучше всего здесь? Спасибо огромное!

Answer 1

С чисто нормировки точки зрения, вы не хотите, чтобы иметь поле, которое потенциально занимает много места бесполезной информации, как если бы в вашем примере, когда пользователь не ест фрукты. Кроме того, вы действительно не хотите, чтобы любимый фрукт был NVarchar, поскольку «Дыня» и «Арбуз» - это разные вещи (или они есть), или как насчет входа «Aple» в случае аварии.

Если бы это был я, у меня был бы стол с фруктами и таблица ассоциации FavoriteFruit, таблица FavoriteFruit имела бы идентификатор плода и идентификатор пользователя. Если у пользователя нет любимого фрукта, пробел не используется. Кроме того, я бы спросил, могу ли я избавиться от «EatsFruit» и просто проверить запись в таблице FavoriteFruits.

Это говорит о том, что у вас есть настроение, хотя, может быть, и игра немного, это не прощающий грех.

Cheers.

Answer 2

В тот момент, когда вы начинаете сохранять условия NULL в своей таблице, вы знаете, что данные должны быть нормализованы.

Представьте, что у вас есть поле anual_bonus в таблице Employee, но только менеджеры получают бонус. У вас будет много нулей в этой области, что будет пустой тратой.

В этом случае я бы

Пользователь:

user_id 

EatFruit:

user_id 
    favorite_fruit_id (can be null if user eat fruit but doesnt have favorite?) 

Фрукты

fruit_id 
    fruit_name 

так, чтобы пользователь, как фрукты вы

SELECT user.* 
FROM user 
LEFT JOIN EatFruit 
     on user.user_id = EatFruit.user_id 
WHERE EatFruit.user_id IS NOT NULL