Текущая структура:
users
id | first_name | last_name |
---|---|---|
2 | Сергей | Иванов |
3 | Иван | Петров |
5 | Виктор | Сидоров |
goods
id | name |
---|---|
50 | утюг |
30 | кофеварка |
20 | телевизор |
33 | ноутбук |
order_items
id | user_id | address | good_id | price |
---|---|---|---|---|
8 | 2 | Москва, ул. Промышленная | 50 | 1000.00 |
2 | 3 | Самара, ул. Энгельса | 30 | 5000.00 |
7 | 5 | Омск, ул. Дворцовая | 50 | 1000.00 |
4 | 5 | Омск, ул. Дворцовая | 20 | 6500.00 |
9 | 2 | Москва, ул. Матросова | 33 | 20000.00 |
6 | 2 | Москва, ул. Матросова | 33 | 20000.00 |
Третья нормальная форма, так же как и вторая, включает в себя два пункта:
Стоимость заказа зависит от цены товара, но в то же время, цена товара, как это ни странно, зависит от самого товара, то есть от good_id. Для приведения таблицы к третьей форме, нам нужно вынести цену в товар:
goods
id | name | price |
---|---|---|
50 | утюг | 1000.00 |
30 | кофеварка | 5000.00 |
20 | телевизор | 6500.00 |
33 | ноутбук | 20000.00 |
И наша таблица приобретает такой вид:
order_items
id | user_id | address | good_id |
---|---|---|---|
8 | 2 | Москва, ул. Промышленная | 50 |
2 | 3 | Самара, ул. Энгельса | 30 |
7 | 5 | Омск, ул. Дворцовая | 50 |
4 | 5 | Омск, ул. Дворцовая | 20 |
9 | 2 | Москва, ул. Матросова | 33 |
6 | 2 | Москва, ул. Матросова | 33 |
С одной стороны, мы выполнили большую часть необходимой нормализации, с другой, новая структура имеет фатальный недостаток. Цена товара, вещь изменяемая, а вот стоимость покупки которую мы совершили в прошлом – нет. Но если нормализация выполнена целиком, то при изменении цены товара, изменится стоимость абсолютно всех совершенных покупок, в которые входил данный товар. С точки зрения бухгалтерии и истории покупок это недопустимо.
Это значит, что цена товара должна копироваться в таблицу order_items. Но и в таблице goods она тоже нужна. В первую очередь для вывода на сайте на витрине.
А что насчет адреса? Адрес тоже зависит от пользователя, но более сложным образом. Один пользователь может иметь несколько адресов (от нуля до бесконечности). Учитывая все что мы говорили про нормальные формы, перенести адреса в таблицу пользователей нельзя. Мы не можем хранить несколько значений в одной колонке и не можем дублировать записи, так как нарушится уникальность первичного ключа.
Правильное решение – завести под адреса свою собственную таблицу. В этой таблице адрес будет связан с пользователем, а вместо поля address в таблице заказов появится поле user_address_id.
Так, по крайней мере, мы бы поступили в теории. На практике же, неизвестно нужно ли выносить адрес или нет, все зависит от конкретной бизнес-логики конкретного приложения.
Вам ответят команда поддержки Хекслета или другие студенты.
Выделите текст, нажмите ctrl + enter и отправьте его нам. В течение нескольких дней мы исправим ошибку или улучшим формулировку.
Загляните в раздел «Обсуждение»:
Профессиональная подписка откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, проектам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.
Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно.
Наши выпускники работают в компаниях:
Зарегистрируйтесь или войдите в свой аккаунт