Как лучше хранить такое в БД?

Question

[E6APB]

Сервис такси. Таблица заказов. У заказа есть свой исполнитель - водила. У водилы есть машина. Что лучше хранить в заказах? Создать колонки driver_id и car_id или создать колонку car_id, и по ней joinом искать водилу?

Answer 1

[i_visseri]

я думал над вашей задачей и сделал вывод, что наверно лучше в orders хранить и car_id и driver_id. Попробую объяснить свое видение - если мы даже уберем car_id и оно будет в табличке водителей, то все равно для сообщения описания машины пользователю - придется делать JOIN. От JOIN'ов мы никуда не уйдем. Но возможен такой кейс: пользователь может выбирать на ходу машину по классу(econom, business) и тогда логично обновлять строку заказа в соответствие с выбранной машиной. То есть с точки зрения вашей предметной области заказ - это водитель + машина(разного класса). Но это только мое мнение, было бы интересно и другие услышать.

Answer 2

[Принц Датский]

Все зависит от физической стороны вопроса, а именно
Может ли одна и та же машина быть у разных водителей?
Может ли у одного и того же водителя быть несколько машин?
В зависимости от ответов на эти вопросы, решение вам придёт само. Нет смысла делать задвоение. Джоин все равно нужен будет. А так- лишние поля, буду дублированные.

Answer 3

[d-stream]

Заказ может еще и измениться по ряду причин.
Притом его может как отменить клиент, изменить маршрут, так и поломаться авто или же косякнуть водитель.
Все это в том или ином виде будет очень полезно для статистики-аналитики-рейтингов.

Так что как минимум сущности "клиент", "авто", "водитель" + пачка действий по заказу.
Последнее косвенным образом позволит отбирать занятых/свободных водителей и автомобили.

Естественно не помешает информация о локациях "куда подать авто", "куда ехать", временах и пробегах.

Answer 4

[entermix]

cars
id, numberplate, ...

drivers
id, car_id, first_name, last_name, ...

clients
id, phone_number, ...

orders
id, driver_id, client_id, sum, ...