Author the new oneArhat1092. Запретить редактирование тайно и вежливо... добавляем признак актуальности записи и вместо редактирования, деактивируем старую запись добавляя новую втихаря...

Не взлетит - если для конкретно Древлеваси Пупкина мы написали, что он покупает не switch, но Концентраторъ сѣтевой , то мы должны при сохранении документа а)сохранить новую версию товара с наименованием " Концентраторъ сѣтевой " и б)сохранить ЕЩЕ одну новую версию товара со старым наименованием switch. Почему еще одну? Потому что, как мне кажется, если уж пошел по этим граблям, то разумнее держать историю названий ("как мы называли свитчи в разное время"), а не просто беспорядочную кучу; что еще интереснее, если все-таки держать беспорядочную кучу, то получается какой-то неопрятный вариант, от которого так размашисто открещиваются.

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

Кстати, во многих ERP строки до и после проведения в разных таблицах хранятся. КМК в этом случае в таблице "до проведения" можно ссылками работать (а может и нужно, что б инфа, например, о том же названии актульная была). За исключением цены, конечно, хотя цена вообще из прайсов берется или вычисляется, а в этом случае можно базовую цену отслеживать по ссылке. А в таблице "после проведения" атрибуты товара, необходимые в документах, надо прямо в строках хранить (целиком инфу о товаре копировать, конечно, не нужно, в исходных строках много лишнего, что для проданного товара не нужно... как здесь сказали "другая сущность"). Эту таблицу можно и не связывать, единственно для удобства пользователя через интерфейс организовать поиск по идентификатору, типа по EAN,... если в каталоге осталась такой товар, пусть покажет. Схема из практики, возникла при переходе на новую систему, когда удалили кучу старых артикулов. Так народ совершенно не напрягался. когда система вместо карточки товара показывала сообщение "товар устарел", да и редко это было.

Но я не настаиваю. Вообще спор ни о чём. Каждое решение хорошее, если оно подходящее.

ЖоаоArhat109... вместо того чтобы понять(всего лишь!) что товар в каталоге и (проданный) товар в заказе - это … две отдельные Сущности со своими Связями... и все дальнейшие "расчеты"/"статистика продаж"/etc (можно подчеркнуть всё) ведется с табличкой проданных товаров (можно даже отдельно держать)... ну ни причем там (в заказе) ссылка на прайсовую позицию, пардон на исходный каталог товаров...
А теперь представьте себе реальный мир:
Вы купили 16 одинаковых предметов в двух партиях по 8 штук у разных поставщиков, у первого в документах предмет зовется switch, у второго — hub. А у вас покупают 13 штук разом. А у меня оно в каталоге заведено как "Коробка с проводами" и я ее так и продам". В чем проблема то?

Author the new oneСпор как раз очень о чем - спор о том, как легко сделать крупную ошибку и потом ее долго не замечать.

Ка известно "если что-то на что-то похоже, то это оно и есть". Можно ли назвать ошибкой рабочее и безпроблемное решение? Возможно через 10 лет потребуется перепроектирование, но также возможно что к тому времени контора 2 раза закроется. Нафига тогда заранее бороться с мифическими ошибками, если это и не ошибка даже, а подходящее под текущую ситуацию простое рабочее решение?

Author the new oneArhat109_мод,

Да ладно сочинять-то! Вы "полное отрицание" каких-то там "принципов" где нашли? :)

Мою жену одна почтенная насельница монастыря давеча на праздниках уверяла, что слово "кошмар" - оно неправославное, потом что от злых языческих демонов происходит, Кошов и Маров. Quelle cauchemar, а я ведь и не знал! (Самое смешное, бабка не так уж неправа, но, подозреваю, даже и не догадывается об этом).

Если оставить почтенных насельниц и обратится к местным насельникам, то было бы недурственно вспомнить определение 3НФ:

википиелияПеременная отношения R находится в 3NF тогда и только тогда, когда выполняются следующие условия:

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


Так вот, название в счете именно для Васи "Лопата саперная гламурная" функционально зависит только и исключительно от ПК детализации счета. Ага.Сильно! только пока непонятно, почему это аргумент против того, что говрит Arhat109.

_модArhat109P.S. вот сколько фантазёров ни спрашивай - ведь ни разу не показали ещё на источник... "своих не выдаем"! :)
Начните с начала:
Мартин Дж. - Организация баз данных в вычислительных системах Это Вы сейчас о чем? У меня эта книга как раз под рукой :). Где там написано про "Товар -объект, прайс-лист -объект, имеющий св-во объект Товар, аналогично накладная?". Или про историю изменений, как универсальный механизм? Что то Вы попутали.

Author the new oneIzyaСильно! только пока непонятно, почему это аргумент против того, что говрит Arhat109.


автор Третий закон Чизхолма.
Любые предложения люди понимают иначе, чем тот, кто их вносит.
Следствия.
1. Даже если ваше объяснение настолько ясно, что исклю-
чает всякое ложное толкование, все равно найдется человек,
который поймет вас неправильно.

Главное в споре — вовремя перейти на личность… (М. Жванецкий). :)