Третья нормальная форма

Текущая структура:

users

id	last_name	first_name
2	Мусаев	Самат
3	Темиров	Айбек
5	Саматов	Манас

goods

id	name
50	утюг
30	кофеварка
20	телевизор
33	ноутбук

order_items

user_id	good_id	address	price	id
2	50	Бишкек, ул. Интергельпо	1000.00	8
3	30	Ош, ул. Айтматова	5000.00	2
5	50	Талас, ул. Манаса	1000.00	7
5	20	Талас, ул. Манаса	6500.00	4
2	33	Каракол, ул. Токомбаева	20000.00	9
2	33	Каракол, ул. Токомбаева	20000.00	6

Третья нормальная форма, так же как и вторая, включает в себя два пункта:

Таблица должна быть во второй нормальной форме
Все колонки в таблице зависят от первичного ключа и не зависят друг от друга

Стоимость заказа зависит от цены товара, но в то же время, цена товара, как это ни странно, зависит от самого товара, то есть от good_id. Для приведения таблицы к третьей форме, нам нужно вынести цену в товар:

goods

id	price	name
50	1000.00	утюг
30	5000.00	кофеварка
20	6500.00	телевизор
33	20000.00	ноутбук

И наша таблица приобретает такой вид:

order_items

user_id	good_id	address	id
2	50	Бишкек, ул. Интергельпо	8
3	30	Ош, ул. Айтматова	2
5	50	Талас, ул. Манаса	7
5	20	Талас, ул. Манаса	4
2	33	Каракол, ул. Токомбаева	9
2	33	Каракол, ул. Токомбаева	6

С одной стороны, мы выполнили большую часть необходимой нормализации, с другой, новая структура имеет фатальный недостаток. Цена товара, вещь изменяемая, а вот стоимость покупки которую мы совершили в прошлом – нет. Но если нормализация выполнена целиком, то при изменении цены товара, изменится стоимость абсолютно всех совершенных покупок, в которые входил данный товар. С точки зрения бухгалтерии и истории покупок это недопустимо.

Это значит, что цена товара должна копироваться в таблицу order_items. Но и в таблице goods она тоже нужна. В первую очередь для вывода на сайте на витрине.

А что насчет адреса? Адрес тоже зависит от пользователя, но более сложным образом. Один пользователь может иметь несколько адресов (от нуля до бесконечности). Учитывая все что мы говорили про нормальные формы, перенести адреса в таблицу пользователей нельзя. Мы не можем хранить несколько значений в одной колонке и не можем дублировать записи, так как нарушится уникальность первичного ключа.

Правильное решение – завести под адреса свою собственную таблицу. В этой таблице адрес будет связан с пользователем, а вместо поля address в таблице заказов появится поле user_address_id.

Так, по крайней мере, мы бы поступили в теории. На практике же, неизвестно нужно ли выносить адрес или нет, все зависит от конкретной бизнес-логики конкретного приложения.