Конспект по подкасту, ссылка на видео дана в конце статьи
Подборка задач
Задача 1.
Есть интернет магазин, в котором пользователи могут заказывать различные товары. Опишите, как организовать хранение данных в базе данных для учета пользователей, товаров и заказов.
справа Entity Relation для создания таблиц. (использовать List не надо, они для списков)
Удобство в draw.io, есть первичный ключ, можно задать вторичные ключи.
Сразу 3 поля (можно уточнить поля у интервьюера, но придумать поля приветствуется)
Название таблиц желательно на английском (но можно и на русском назвать сущности)
Главное чтобы базы назывались в одинаковом количестве **обычно в единственном** (или заказы тогда товары, или заказ тогда товар)
вписывам id
если логическая схема (достаточно id)
если физическая модель
то прописать
- тип UUID
- UNIQUE - уникальное
- NOT NULL - обязательное
Заполняем поля
Дополнительные атрибуте, если физическая модель
- телефон - UNIQUE (уникальный)
Товар
название (спросить должен ли быть уникальным?)
цена в копейках - Integer
у товара может быт много изображений - массив ссылок это не хорошо
можно сделать дополнительную таблицу
Заказ
Пользователь USER_ID
и есть FK и задается связь (Стрелочки нет просто линия) -- далее проставив 1 или * продумаем какая это связь
Поля:
- Дата
- Адрес доставки (копировать из настроек пользователя)
По хорошему нужно структурировать адрес
где все прописано
и ссылаемся стрелочкой
-- Называется: Структурированный адрес.
И есть связь товары в заказе
!!!Ошибка!!! получается в 1 заказе только 1 пользователь.
Но у одного пользователя может быть много заказов
ставим звездочку
далее выбираем большую кратность
1 пользователь - много заказов
- зеленым цветом выбираются кратности
Многие
- внешний ключ там где многие
где 1 там первичный ключ
Пропишем заказ
соберем из листов пример
id - номер - пользователь_id - Дата и время (timestamp)
Пользователь
Ссылка на конкретный пользователь
1 - пользователь 2 заказа
1 пользователь 1 заказ
Важно:
В модели таблицы не прописываем демо значения
Товар
можно добавить столбец со ссылкой с троеточием
Заполняем таблицу
-- цены в копейках
Почему связь сразу
Пользователь - Заказ (она ставиться сразу она не проблематичная)
а вот заказ - товар
(может быть несколько товаров в 1 заказе, и несколько заказов с одним товаром)
Важно: многие ко многим быть не должно
их надо развязать
-- И вводим промежуточную таблицу
Почему вводим?
при добавлении в заказ 2-х товаров - 777 и 779
-- 2 строчки со всеми полями дата пользователь ... начинает дублироваться
---- Это проблема и если поменять имя пользователя, номер то нужно обновить 3!!! записи вместо 1 !!!
(Это нарушает требование нормальных форм)
Поэтому такую колонку убираем и отслеживаем чтобы такого небыло
Внешняя таблица
- как назвать (Заказ_Тавар)
- не нужен первичный ключ PK - (нужен если будут доп поля )
Многие в промежуточной таблице
1 - по краям
на товар мы ссылаемся на конкретный товар
Таблица (Заказ-Товар)
и в одной таблице соответствие Заказа_ID и Товар_ID
и если есть дата и время оплаты,
-- Если данные в таблице заказ обновилось время
-- ТО не надо обновлять 50 строк -> достаточно в заказе обновить время
В итоге
Подвох про интернет магазин
количество товаров в таблице Заказ-Товар
Историчность
- могут в разные данные меняться цены
ТО добавляем поле статус в Заказ
И Цена в Заказ_Товар
КОГДА статус обновился - цена зафиксировалась (оплата прошла)
(Очень полезна когда цена рядом с заказом )
Тоже можно делать с названием, и оставлять возможность замены при прохождении статуса - Оплата