Заказ, Заказ, Товар. Написать информацию о продукте в OrderItem?

Это не вопрос о конкретной технической проблеме, а более общий вопрос о дизайне базы данных. Тем не менее, технический стек таков: ASP.NET MVC, SQL DB.

Недавно я унаследовал систему, в которой есть концепция «Заказ» -> «Элемент заказа» -> «Продукт», т. Е. В заказе много элементов заказа, и каждый элемент заказа связан с одним продуктом.

Элемент заказа сохраняет следующее при сохранении в БД:

  • Номер заказа
  • Код товара
  • Кол-во
  • Стоимость единицы (написано из продукта)
  • Итого NET (рассчитано на основе Кол-во * Стоимость единицы)
  • НДС
  • Всего БРУТТО

Элемент заказа, просматриваемый через пользовательский интерфейс, выглядит следующим образом:

Qty | ProdCode | ProdDescription | Unit Cost | Total NET | VAT | Total Gross

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

Все кажется достаточно разумным.

Итак, мой вопрос вращается вокруг того, какие данные должны быть записаны из продукта, а какие данные должны быть ссылками из продукта. В частности, стоимость единицы записывается из продукта, когда создается элемент заказа. Я предполагаю, что это связано с изменением цен на товары, и вы не хотите, чтобы это изменение применялось к старым заказам. Хорошо, имеет смысл.

Мой вопрос: должна ли та же логика применяться к коду продукта и описанию продукта? И если нет, то почему?

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

Разработчик, создавший систему, больше не может обсуждать свои мысли при ее проектировании.

Система работает нормально, нареканий нет. Однако это в основном потому, что никогда не было никаких обновлений кодов/описаний продуктов, хотя они доступны для редактирования для различных пользователей.

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


person lee_mcmullen    schedule 04.02.2016    source источник
comment
Никто за пределами этой системы не может ответить вам на этот вопрос. Я предполагаю, что ProductCode может измениться? Я понятия не имею, что такое ProductCode. Кроме того, я вижу сохранение ProductDescription с заказом. Описание может меняться, и в зависимости от системы может иметь смысл сохранить его вместе с заказом на случай, если потребуется фактическое описание во время заказа. Я мог бы увидеть путаницу, если бы заказал этот продукт красного цвета, но теперь в моей истории заказов есть описание «Этот продукт больше не красный».   -  person Sean Lange    schedule 04.02.2016
comment
Да, Шон. Именно эта путаница меня и беспокоит. Если Описание Продукта (на Продукте) значительно изменится, то, как в настоящее время работает система, все предыдущие заказы, которые ссылаются на этот Продукт, теперь будут отображать описание, которое отличается от первоначально заказанного. Что мне кажется плохим.   -  person lee_mcmullen    schedule 04.02.2016


Ответы (1)


В таких случаях необходимо учитывать несколько аспектов. Начнем с того, что заказы ДОЛЖНЫ быть неизменяемыми.

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

Другой подход заключается в том, чтобы никогда не оставлять код продукта и его описание неизменными.

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

person Zohar Peled    schedule 04.02.2016
comment
Зоар. Да, ваш второй подход - это решение, которое я думал реализовать, чтобы избежать дублирования большого количества данных, как вы правильно сказали. Спасибо за ваши комментарии. - person lee_mcmullen; 04.02.2016
comment
На самом деле, если они никогда не менялись, вы можете подумать о том, чтобы сделать их неизменяемыми и закрыть эту опцию для клиентов администратора. это будет самое простое решение... - person Zohar Peled; 04.02.2016
comment
Согласовано. Да, поля «Код/Описание» не изменились, но записи о продуктах доступны для редактирования через пользовательский интерфейс определенным пользователям, а цены изменились. Для начала я отключу возможность редактирования полей «Описание/Код» и посмотрю, не жалуется ли кто-нибудь. Если они это сделают, я создам правильное решение. - person lee_mcmullen; 04.02.2016