Arhat109Копирование товара в заказ - никак не мешает его жизненному циклу.

alexeyvg, сам товар - такое же значимое поле. Сущность Цена - просто проявляет те же самые проблемы, значительно чаще и шустрее, но сами проблемы - в точности такие же.Да это понятно. Но на практике остальное для заказа не так уж и важно.

А копирование товара в заказ проблемы не решит, потому что с товаром ещё много чего связано. Это получается совет вообще не делать ссылок на записи в БД, а всегда копировать запись целиком вместо ссылок? Чем заказ отличается от сотни других сущностей, в которых есть ссылка на товар?

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

Arhat109MasterZiv, данные - они всего лишь данные. И когда они больше не нужны БЛ, их можно (иногда и нужно, и даже необходимо) удалять из БД. Другой вопрос "когда и как"... можно и логически, можно и путем добавления признака "активная запись", можно и путем переноса в архивное хранилище, можно и ... конкретное применение - сильно зависит от задачи.Я понимаю вашу позицию и целиком поддерживаю.

Только сейчас мы ведём речь о тех данных, которые нужны в БД.

ТС ясно сказал - ему нужны данные о заказах и о товарах, которые включены в этот заказ.

Обсуждать, как правильно удалить эти товары из базы в таком контексте глупо.

Вы же не предлагаете просто время от времени удалять товары, например, по принципу "в настоящий момент отсутствуют на складе"?

Это всё есть "активные" данные, они естественно в базе нужны.

Как отделить "неактивные" данные и собрать мусор - это отдельная тема.
И в принципе действительно на самом деле проще никогда не удалять, это просто намного дешевле. Реально даже крупная компания за свой жизненный цикл обычно работает с настолько мизерным количеством товара (ну, несколько милионов, ну пусть даже 100 милионов, это вообще какой то монстр), что разница в стоимости удаления и хранения лишних данных соверешнно очевидна.

Arhat109Я написал первый пост несколько из других соображений, а именно из необходимости абстрагировать заказ от других сущностей в БД. Не вижу принципиальной разницы между "названием" и "ценой" товара. И то и другое - суть атрибуты, имеющие свойство меняться со временем (например исправление опечаток в названии или сознательное отстраивание от названия конкурента - видел и такое).

Почему тогда копирование цены в заказ - не вызывает вопросов, по сравнению с названием?

Банально: нет копирования, есть только ссылка на каталог. Что имеем:
состояние 1: выписка заказа по первоначальному названию. Отправка заказа клиенту.
состояние 2: изменение названия. -> автоизменение содержимого заказа на новое название (проблема таже что и с ценой!)...
состояние 3,4: отгрузка товара по новому названию и отправка накладной с новым товаром

... в итоге получаем рекламацию: пересортица при поставке!Выглядит абсурдом. Какое то автоизменение цены, названия :-)

Независимо от того, изменилось назвыание товара или нет, отгружен будет именно тот товар, который привязан к заказу. Не по названиям же кладовщик отгружает :-)

Сохранение каталожной цены товара в момент продажи может быть полезно для неких статистических расчётов, но к самим бизнес-процессам не имеет ровно никакого отношения, так же, как и название товара.

Оба аттрибута товара - название и цена - для заказа и всех процессов совершенно бесполезны, не имеют ровно никакого значения.
Но цена сохраняется, как я уже сказал, для получения статистик, название товара, конечено, можно тоже сохранять для этих целей, но в жизни я таких целей не встречал.
Arhat109и вот на такую пересортицу я в своей практике - реально натыкался!
строка заказа (за точность номера железки не ручаюсь):
HUB 3COM-15712-ME 10шт.

строка счет-фактуры и накладной на следующий день (это реальная ситуация)

SWITCH 3COM-15712-ME 10шт.

реакция получателя (почта, наложенный платеж, оплата доставки продавцом): это не тот товар, который был закуплен. Верните продавцу обратно.Это не пересортица.
Счёт-фактура или накладная - это не заказ, это отпечатанные документы, их понятно нужно сохранять полностью, само собой.
NetObserverРешение проблемы 2) - глубокая оптимизация, вещь трудозатратная, неблагодарная, трудно-объяснимая для начальства\бизнеса.Да не глубокая оптимизация, а правильное место роста рук :-)

Прямо так страшно, "глубокая оптимизация", и с придыханием "целых десять тыщь товаров!!!"

Что это за программисты, если у них на 10К записей тормоза? ну и понятно, что тогда варианты В) и Г) для них полностью недоступны.