Нужна ли денормализация?

Question

[l4m3r]

Допустим, есть таблица клиентов:

clients
	id
	first_name
	last_name
	middle_name
	phone
	email
	passport_series
	passport_number
	passport_issued_on
	passport_issued_by
	place_of_residence
	drivers_license_number
	comment
	status

Нужно ли, по-хорошему, в таблице заказов orders(id, client_id, ...) дублировать все поля (id, client_id, client_first_name, client_last_name, ...)? С одной стороны, так заказ фиксируется неизменным навсегда, даже в случае удаления клиента или изменения его данных. Но с другой - кошмарная избыточность, ведь в таблице заказов может быть еще другие связи 1 к 1 и в итоге полей будет миллион.

Или может делать суммирующее поле типа orders(id, client_id, client_info (Иванов И. пасп. 0301 333333, тел [phone])?

Или может делать доп поле orders (client_id, client_data), где в client_data запихать json записи из client, что в случае чего восстановить запись.

Как правильней поступить?

Comments

[alex-1917]

10 заказов в месяц - и вы боитесь избыточности?)))ОоОоОоОоО
заказы обязательно в отдельной таблице.

[l4m3r]

alex-1917, как связана избыточность и количество заказов? Причем тут вообще производительнось? Хоть 0 заказов. Вы читали вопрос? Меня интересует как правильно построить таблицы.

[alex-1917]

l4m3r, я свой ответ дал.
а по факту, судя по вашей реакции,я на минуточку представил себя вашим наемным работником. или как будто вы мне сделали предоплату и что-то требуете взамен...такой приказной тон... но нет.. вряд ли...
это конечно ничего страшного, но три жалобы легко и непринужденно отправляют подобные вопросы в баньку...

[l4m3r]

alex-1917, единственное, что вы сказали — "заказы обязательно в отдельной таблице". Но об этом и любой идиот догадается. Остальное — полный бред. Напрашивается вывод, что вы просто некомпетентны.

Answer 1

[Иван Шумов]

Ответ от человека, который 5 лет работает с подобной системой и которая себя уже осознала.

Вы правы только от части. У вас есть две сущности - заказ и клиент. В зависимости от вашей сферы есть инициатор заказа, имя на которое сделан заказ и способ связи по заказу.

Как зовут и как связаться с тем кто вам позвонил вы никогда гарантировать не можете на самом деле. Кроме того у клиента моет быть несколько номеров телефонов и почт.

Могу посоветовать вам в случае явственного соответствия клиента и привязывать его через client_id и дублировать его ФИО в client_title (например), а так же ожидаемый контакт для связи.

Если вы будете вести только клиентскую базу то быстро упретесь в том что люди часто меняют телефоны и потом дозвониться до клиента станет невозможно. Вы убьетесь поддерживать эту информацию (вы же не ФСБ, ну)

Comments

[l4m3r]

Ну там кроме телефона ещё паспотные данные, номер ВУ, ФИО. Заказчику хотелось бы упросить себе жизнь не набивая это при каждом заказе. К тому же специфика такова, что клиентская база не сильно большая и много постоянных клиентов. В год заказов 200-400.
Заказчику было бы удобнее, когда приходит клиент, ввести его номер телефона / фамилию, сверить инфу и уже одной кнопкой наполовину заполнить форму заказа автозаполнением.

[Иван Шумов]

как я уже писал отдельно - очень зависит от процессинга. Нужен ли доступ к заказу не имея доступ к клиенту, например?

[l4m3r]

Иван Шумов, не нужен. это простая система и нужна одному-двум людям. это crm на одного пользователя - заказчика. И прав - только доступ в crm'ку и всё. Заказчик просто сейчас в excel'е всё ведёт.

[l4m3r]

Иван Шумов, и нельзя сделать не на себя. Клиент приходит, его заказ зарегали, он оплатил и сразу получил услугу

[Иван Шумов]

l4m3r, если нет процессинга то важно иметь возможность восстановить данные на любой момент времени, ведь они меняются. А дальше смотреть по росту системы

Answer 2

[Decadal]

Нужно ли, по-хорошему, в таблице заказов orders(id, client_id, ...) дублировать все поля (id, client_id, client_first_name, client_last_name, ...)? С одной стороны, так заказ фиксируется неизменным навсегда, даже в случае удаления клиента или изменения его данных. Но с другой - кошмарная избыточность, ведь в таблице заказов может быть еще другие связи 1 к 1 и в итоге полей будет миллион.

У вас не должно быть удалений клиентов. Функцию удаления достаточно реализовать через soft delete (флаг deleted_at).
Кстати а для заказа есть смысл делать другую таблицу. Historical_order_client - на тот случай если нужно запоминать факт с каким телефоном и фамилией был клиент (фамилии и телефоны меняются, а надо ли их менять в заказах - вам виднее).

Или может делать суммирующее поле типа orders(id, client_id, client_info (Иванов И. пасп. 0301 333333, тел [phone])?

нет. Это относится к оптимизации. Пока у вас нет жалоб на скорость работы, не заморачивайтесь. А когда будут, то введение калькулируемых полей в базу это не самый первый метод оптимизации который нужно применять.

Или может делать доп поле orders (client_id, client_data), где в client_data запихать json записи из client, что в случае чего восстановить запись.

не стоит

Comments

[Иван Шумов]

про удаления согласен, про json не совсем согласен. Наша система бронирования и система билетов показала что далеко не всегда люди делают заказы на себя

[Decadal]

"Наша система бронирования и система билетов показала что далеко не всегда люди делают заказы на себя"

зависит от предметной области. Я кстати тоже работаю с системой бронирования - у нас отдельно "турист" и "заказчик".

[l4m3r]

То есть дублирования полей делать не стоит? Можно ограничиться orders(id, client_id), сделать soft delete, и сохранение исторических данных (json или таблица)?

[Иван Шумов]

l4m3r, зависит от предметной области, но в целом стоит. Например, если вам необходимо иметь процессинг с заказами на постобработку, но не давать доступ к базе данных клиентов (как у нас с валидацией заказов) то это лучшее решение

[Decadal]

l4m3r, да, но вы смотрите и на другие ответы. Я просто делюсь опытом как делается, а вы сравните мой ответ и остальные, и найдите подходящее для себя решение. В любом случае, денормализировать без причины не стоит, потому что вы потом столкнетесь с грудой вопросов "как это у этого заказа клиент 111 Евгений а в самом заказе Арсений, а изменения имени в логах активности нет"
ведь с вашей системой будут работать другие программисты (возможно), и не все поймут целей такого дублирования, если вы за этим не проследите.

Answer 3

[LamerToExpert1]

TAB - orders (id, client_id, .... ) в чем проблема просто оставить так , зачем переписывать данные и в orders ?

Comments

[l4m3r]

А если я или кто-то изменил его данные? Допустим в заказах 2017 года у него был один паспорт. А в 2018 он паспорт поменял и мы, соответственно изменили таблицу clients с этим. И в итоге окажется что в 2017 у него был новый паспорт.

Answer 4

[sim3x]

0. Спросить у заказчика
1. Избыточность будет на миллионах записей
2. Выборки по жсону - сейчас досточно быстрые

Comments

[l4m3r]

Не понял. Так каков ваш совет в итоге? json или доп поля?

[sim3x]

l4m3r,
0. !
1. Не беспокоится по поводу избыточности
2. Если выберете хранить в жсоне, то все равно можно будет делать агрегацию по заказам

[l4m3r]

2. Если выберете хранить в жсоне, то все равно можно будет делать агрегацию по заказам

mysql умеет?

[sim3x]

l4m3r, постгрес умеет

[Иван Шумов]

l4m3r, вы можете использовать nosql базу. Там таких вопросов не встанет

[sim3x]

Иван Шумов, там встанут вопросы посложнее или не решаемые нормально

[Иван Шумов]

sim3x, в любом решении есть плюсы и недостатки. Это trade-off

[sim3x]

Иван Шумов, в случае nosql недостатки с неудобствами

[Иван Шумов]

sim3x, расскажите об этом мне, я послушаю) у меня в проектах штук 5 разных баз под свои задачи) есть SQL и nosql. Каждое решение под свой use case.

Answer 5

[Андрей Скоржинский]

А вот товарисч похожую задачу решал

Comments

[alex-1917]

у автора 10 заказов в месяц)))