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


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

Переход на личности, часть третья. То есть вот этот пост писали не Вы 13742971 ? (третья строка сверху), что там Вас "устраивало"? А ровно следующий пост - и есть "тот самый гемморой" из моей цитаты... это с вашей стороны не враньё, просто склероз... так? :)

Далее. Это 13744964 своё враньё как объясните? Полетом фантазии? О какой фальсификации речь была, показать сможете или тоже "замнёте для ясности" как тут многие поступают? :)

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

Теперь, будьте также добры, ответить на то что написали (я Вам тоже покрасил жирненьким), где Вы у меня это нашли? или враньё, но уже Ваше?

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

vladimir74,

а вот не надо "выборочно"... речь о том, что
1. вставлять ссылку на номенклатуру в строку заказа - опасно ошибками в документах при переименовании наменклатуры...
2. что нет никакой разницы с точки зрения проектирования между ценой товара и его наименованием... это одно из его свойств и только.
3. решений кроме озвученных тут 13737500 - никто не представил. Но для простой структуры ТС - они достаточно избыточны.
4. Представленное решение:
а) исправляет такую ошибку проектирования (а это именно ошибка проектирования);
б) позволяет делать модульный код и развивать его постепенно;
в) позволяет использовать Историю и прочие решения по назначению;
г) разгружает модули работающие с данными от избыточных данных, избыточных блокировок и т.д.
г.1) модуль продаж - работает со своей частью БД и может почти ничего не знать о модулях снабжения, склада и т.д.
г.2) модуль снабженца - работает самостоятельно и может также почти ничего не знать о продажниках
г.3) модуль истории изменений - занят своей работой и не мешает остальным старыми записями
г.4) ...

Поскольку другого решения для простой структуры ТС - тут не представлено, то "спора" как такового нет. Есть непонимание работы решения (что странно) и откровенные наезды(что тут принято).
То есть треп. Мне приходится защищать представленное решение. Фсё.

P.S. Я уже писал, что в мире существует много разных и профессиональных решений, применяемых на практике... но тут (перечитайте первый пост ТС) о них речь не идет. У чела есть каталог товаров и таблица заказов, в которую он пихает внешний ключ на товар из каталога
... я предложил ему копировать наименование (можно до кучи к ссылке)... это и вызвало весь этот треп. Народ решил посмеяться...

правда похоже что мне - уже смешнее. :)

Chop,

Вы продолжаете откровенно троллить. Это всё? Аргументы кончились (впрочем от Вас их и не было)? :)

ViPRos,

тоже склероз... я уже писал об этом несколько страниц взад. Мне - ссылок не надо (и я их не просил, и Вы не выясняли знаю я их или нет - фантазировать тут принято, тока обижаться потом не надо)

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

что так теперь-то возмутило? :)

_модArhat109... мне тут пытаются доказать обратное, типа "история" спасает.
Спасает, спасает... бюджет разработчика от разорения. :)
Ваши наколенные поделки стоят дороже. Не надо чужие деньги считать, вопрос чисто технический

мои наколенные поделки - обошлись мне в 3 месяца основной разработки и около года расширения функционала, в основном в сторону СРМ (как оно теперь называется, тогда их просто не было)... и около 3-х лет функционирования всего предприятия из 3-15-37 человек.

при этом, "крутыми специалистами", с которыми в том числе, консультировались начальники отделов ИТ и ВЦ достаточно крупных контор ... ага, были девочки, ни разу не способные отличить факс от монитора. Они просто грамотно умели читать (значительно лучше некоторых тут)...
... да и такая должность как "снабженец" - отсутствовала как факт, потому что вопрос "где взять дешевле и качественне" - не стоял. Комп считает лучше любого снабженцу... и откатов не берет.
:)

Chop, вот на эти 13749630 вопросы ответы давать будете, или предпочитаете остаться вруном?

Chop,

понял, отстал. остаться вруном - предпочтительней. :)

ViPRos,

да, я посмотрел. Впечатлило. Но Вы же не будете мне запрещать фантазировать вслед за всеми (и Вами тоже)? :)

Давайте разберем. Всё лучше чем читать глупости фантазеров. :)

Кот МатроскинСтоп. сколько в итоге таблиц - 3? что такое тогда "синонимы"?
Связь 1:М , моделируемая отношением "каталог товаров(который прайс)" 1 : М "каталог товаров поставщиков".
Кот МатроскинТаблица товаров поставщиков - хранится вечно, данные только добавляются? или обнуляется при каждой приемке всех прайсов?

Обновляется при каждой загрузке. Это текущие складские остатки поставщика с количеством (складом, отдельный набор таблиц).
Кот МатроскинКакова структура таблицы "проданные товары" - те самые 6 полей и все, никаких ссылок ни на что?
(самое главное) Как определяется, что этот товар никогда раньше не продавался?
Давайте лучше конкретный пример разберем.
Вот мы торгуем шапочками.
у нас есть товар "Женская фиолетовая шапочка" и 3 поставщика, которые этот товар нам могут поставлять (А, B, C).
у А этот товар называется "шапочка женская (фиолетовая)", у B - "фиолетовая шапочка", у C - "Шапочка зеленая" (ошибка в каталоге, мы совершенно точно знаем, что при заказе этого артикула нам отгрузят фиолетовую шапочку).
Причем зеленые шапочки у B и С тоже есть (хотя продажи их мы сейчас и не рассматриваем). Поставщик в прайсе, для простоты, дает нам только артикул (у каждого поставщика разный, естественно), название и цену, никаких доп. свойств нет.
В первый день продаж товар есть только у А, во второй день - у B и С, в третий - у С. шапочки заказывают все три дня,
но комплектуем и поставляем товар мы на следующий день после заказа
Как будет работать Ваша приемка прайсов, комплектация заказа, что будет с Вашими таблицами каталогов и с заказами в каждый из дней?
... skipped... пока не нужно


поправлю пример, чтобы было понятней:
1. Есть три поставщика, каждый со своей номенклатурой и артикулами товаров (никаких параметров никто не давал, это сейчас лохов заставляют в xml клепать... :)

"А": "шапочка женская (фиолетовая), артикул А1"
"Б": "фиолетовая шапочка, арт. Б2"
"В": "шапка зеленая, артикул В1" (на самом деле она тоже фиолетовая, но мы пока ещё этого не знаем, так дали)

Обработка:
1. Обработка прайсов (выделяем параметры, теперь это EAV называется, пусть будет "руками оператора")

"товар::шапочка", "пол::женская","цвет::фиолетовая","артикул::А1","артикул::Б2","товар::шапка","цвет::зеленая","артикул::В1"
других нет.

2. Собираем каталог товаров "поставки". Добавляем туда все строки прайсов:
Запись1:: "отА", "шапочка женская (фиолетовая), артикул А1", ценаА1, остатокА1
Запись2:: "отБ", "фиолетовая шапочка, артикул Б2", ценаБ2, остатокБ2
Запись3:: "отВ", "шапка зеленая, артикул В1", ценаВ1, остатокВ1

3. Собираем "прайс-лист" (с учетом параметров строк):
Запись1:: "шапочка женская (фиолетовая)", "артикул мой1", "мояЦена1", "остатокА1+остатокБ2"
Запись2:: "шапка зеленая", "артикул мой2", "мояЦена2", "остатокВ1"

... на самом деле цены, остатки, в дороге, дата прибытия и мн.др. хранилось конечно же не в каталоге... сейчас не суть важно.
... заметьте, что товаров в каталоге стало только 2 (ещё не знаем, что зеленая = фиолетовая, верно?)
... как и писал, наименование в прайс попадало по первому встречному... можно было поправить...

4. Одновременно собирается таблица синонимов товаров поставщиков (оно же) на основе критерия "похожести":
Запись1:: прайс1 = поставки1
Запись2:: прайс1 = поставки2
Запись3:: прайс2 = поставки3

... Шапочка фиолетовая - "похожа" на товар поставщика А и поэтому "объявлена" синонимом (пусть тоже руками оператора, она её купила и носит)

Всё. Часть работы "снабженца" кончилась.

Часть2: пришел новый прайс от поставщика "В" (исправили ошибку - зеленых больше нет, но есть фиолетовая):
в виде текста "шапка фиолетовая, артикул В1" (артикул тот же, так?)

каталог "поставки":
Запись1:: "отА", "шапочка женская (фиолетовая), артикул А1", ...
Запись2:: "отБ", "фиолетовая шапочка, арт.Б2", ...

...не изменились, поскольку обновился один прайс.

Запись3 -- удалена нет таких.
Запись4:: "отВ", "шапка фиолетовая, артикул В1",...

прайс-лист:
Запись1:: "шапочка женская (фиолетовая)", "артикул мой1", "мояЦена1", "скокаНеПродали + новыйОстатокВ"

таблица синонимов:
Запись1:: прайс1 = поставки1
Запись2:: прайс1 = поставки2
Запись3:: -- удалена.
Запись4:: прайс1 = поставки4

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

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

Создаем заказ (счет, и т.п.), каталог "продано" - пуст (копируем строку прайса):
"проданные товары":
Запись1:: "шапка зеленая", "артикул мой2", "ЦенаПродажи1", "кол-во=1"

"проданныеПоставки" (тоже пустой, копируем, товар есть только у поставщика "В"!):
Запись1:: "отВ", "шапка зеленая, артикул В1", ценаВ1, остатокВ1

синонимыПроданного" (тоже пусто - первая продажа...):
Запись1:: "продано1" = "проданнаяПоставка1"

Заказы (строки):
Запись1:: "продан1", ...

ЗаявкиПоставщикам:
Запись1:: "проданная поставка1"

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

Что осталось непонятным? Объем данных в каждой части - оптимально минимален, а стало быть и скорость и размеры... не чета вашим историям.

Для закрепления материала :)
Продажа зеленой (теперь уже фиолетовой) шапки (копирование, не забыли?):

"проданные товары":
Запись1:: "шапка зеленая", "артикул мой2", "ЦенаПродажи1", "кол-во=1"
Запись2:: "шапочка женская (фиолетовая)", "артикул мой1", ...

"проданныеПоставки" (тоже пустой, копируем, товар есть только у поставщика "В"!):
Запись1:: "отВ", "шапка зеленая, артикул В1", ценаВ1, остатокВ1
Запись2:: "отВ", "шапка фиолетовая, артикул В1",...

синонимыПроданного" (тоже пусто - первая продажа...):
Запись1:: "продано1" = "проданнаяПоставка1"
Запись2:: "продано2" = "проданнаяПоставка2"

Заказы (строки):
Запись1:: "продан1", ...
Запись2:: "продан2", ...

ЗаявкиПоставщикам:
Запись1:: "проданная поставка1"
Запись2:: "проданная поставка2"

... по сути - всё. Все документы отписываются абсолютно верно, ровно в той нотации, в котрой они были на момент выписки. Нет?
... статистические расчеты: тоже "не проблема"... если что-то смущает, то по параметру "артикул" - совместите самостоятельно, он в части EAV лежит (там ваще много чего лежит).

Я же уже писал: "лох должен платить"
Думаете почему все так "всполошились"?
:) :) :)