Izya,

... а мне уже показалось, что здесь только ЧАЛ один во всем понимает... :)

На самом деле, вопрос с переименованием товара в каталоге и копированием в заказ - куда как более серъезный. Это то самое "отсутствие связей в РМД", которое приходится всегда делать ручками в ЯП, использующем РСУБД. И это - основной "косяк" М5 связей как не было, так и нет...

Копировать приходится, потому что другого пути - нет. Прайс-лист (каталог товаров) и заказ - это РАЗНЫЕ Сущности и ссылаются они на разные свойства разных товаров (хотя и кажется что вроде одно и то же)...

ваш пример - как раз попытка объяснить это...

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

... забавно, что столько людей, знающих такие вумные термины, способные так красиво писать "пшелнах" ... на самом деле - фик... понимания как у второклассников. Всё что здесь продемонстрировано - это:
а) полное неумение вести дискуссию
б) невоспитанность
в) проф. неграмотность.

P.S. Кстати, насколько помню, в 1С реализован первый вариант "камасутр". :)

Итого, моё предложение ТС-у:

1. Каталог товаров - это, по сути, ваш "прайс-лист". Как и чего в нём названо, сколько стоит, какими ещё параметрами обладает - пофиг. Не играет никакой роли. Отсюда можно удалять, править "всё что угодно"... можете вести версионность, историю изменений (если хочется). Он нужен "для показу" (справочник или витрина вашей БД).

2. Заказы (строчная часть документа, есть ещё и шапка). Сюда копируете(это нормально и дает самое быстрое решение на всех этапах как работы так и последующего развития системы) все значимые параметры из каталога товаров, которые могут быть использованы для дальнейшей работы с документами, статистикой продаж и т.д. Если сильно хотите 3НФ - сделайте отдельно(!) таблицу "проданные товары" и ссылайтесь в строчках заказов на неё. Но никак не на исходный каталог. Заметьте, что тут УЖЕ нет ни истории, ни версионности, ни удалений. Это УЖЕ проданные товары. Поезд ушел. В лучшем случае, можно добавить "архивирование" и удаление ошибочной продажи - сторно (и то осторожно).

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

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

4. Аналогично, поступаете и с обратной стороны - снабжения и соответственно склада: каталог входящих товаров (а равно и склад и приходные документы) - к результирующему прайс-листу (вашему каталогу для показу) - НЕ ИМЕЕТ. Это также разные Сущности.
Только в этом случае, у Вас будет возможность правильно распределить заказ на Поставщиков, даже с разными наименованиями, правильно вести статистику учета приходов и т.д...
... и опять, заметьте - нет тут ни истории, ни версионности... это УЖЕ купленные товары. Поезд опять ушел. В лучшем случае, можно разрешить удаление ошибочной закупки и архивирование. Ограничения - теже что и с продажей.

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

... если бы в РМД были Связи - можно было бы воспользоваться ими. Но их нет. Так что - копировать ручками.

Удачи! и поменьше читайте ерунду предлагаемую как "так точно правильно". К этой рекомендации - относится также (мало ли какая у Вас задача на самом деле).

Бредятина,

тока надо заметить, что структура проектного решения уже сильно отличается от двух таблиц... :)

то самое решение, о котором был спор и смех - как раз ограничивалось ими. И, как ни странно, ни один оппонент никакого другого решения - так и не привел. Так что спора не было. Был проф.непригодный треп.

Бредятина,

верно, именно с этой рекомендации треп и начался... пришлось защищать рекомендацию полноценно. :)

продолжаем веселиться. Часть три. :)

_модArhat109Дык, вот ситуацию с переименованием названия в этом самом "правильном каталоге" и рассматриваем!
Все очень просто: если это ошибка - она исправляется, что делать с ошибочными документами - вопрос второй. Если объект изменяет свое св-во (любое), то старое сохраняется в истории. Все старые документы останутся неизменными.
Что вы ломитесь в открытую дверь, все это давным давно во всех нормальных системах сделано. А ваш подход - это 60-ые годы прошлого века. Тут даже обсуждать нечего.

Да ну? Если (как указано у ТС) ссылка заказа смотрит в единственный каталог товаров , то чем поможет Вам то, что старое значение Вы положили в историю ?!?

Чтобы такое работало (камасутра, вариант 3)
, Вам надо переназначить ссылку на название в заказе на запись о товаре в таблице истории... а это уже совсем другая ссылка (вплоть до динамического SQL)... или изначально вести историю в таблице каталога (база - пухнет, запросы тормозят и усложняются - потому как всё время приходится шариться в истории де факто)... или изначально направлять ссылку из заказа в таблицу истории пихая туда сразу и текущий элемент каталога...

когда пихать элемент каталога в "историю"?
а) сразу при создании элемента -- вариант с историей прямо в каталоге, даже логичнее будет.
б) в момент создания заказа -- угу, код растет, а с ростом количества документов...
в) ваш вариант?

... сравните по стоимости, надежности и долговечности с предложенным вариантом... какой проще в реализации, сопровождении... и т.д.

Итог вашего подхода: "лох должен платить".

... ну и просветите по второму вопросу, в частности "Что делать с ошибочными документами, по которым уже проведена оплата/заключен договор?", особенно для случая систематической ошибки: "изменение наименования поставщиком".

Вот так, ошибка проектировщика вылезает геммороем кодерам, бухгалтерам и всем остальным.
Правильно. Самый верный вариант камасутры - первый (идите нахрен Василий), в смысле совсем, пишите свои документы в Excel, или ваще перьевой ручкой... вот такие современные решения, оказывается. :)

Кот Матроскин,

Забавная фантазия... эту строчку


пропустили, читая "по-диагонали", нет? Если нет, то объяснить соостевтвие написанного Вами этой строке сможете? :)