Arhat109, упустил.

Как определить что этот товар никогда не продавался? По артикулу. Он в моем прайсе выведен в отдельное поле - нафига? Это сквозная уникальная идентификация моего прайса. Если в проданном такого артикула нет - вставляем, есть игнорим.

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

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

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

к примеру, сейчас на портале около 450тыс. позиций, с артикулом из них - хорошо если есть 1%
... тем не менее, распознаваемость "оно же" при обновлении прайса дает достаточно большой процент попаданий... :)

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

Как всё запущено... перечитайте внимательно (система частично УЖЕ воспроизведена на потрале и работает ваще без артикулов поставщиков :). Как поведут себя Ваши таблицы - Вы решили тоже "замять для ясности, нет?

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

Arhat109,

P.S. Всем огромное спасибо, давно так не веселился.
С наступившим Новым Годом и успехов в работе!

Кот МатроскинНет.
Ещё один вменяемый участник трепа... приношу свои извинения, ошибся.
Кот Матроскин Есть таблица наших товаров. Оттуда никогда ничего не удаляется
то есть, "история" копится прямо в вашем прайсе (это же аналог моего прайса, так?)
Если у меня в прайсе, в среднем болталось что-то около 40_000 позиций (комп. железо), с 30% еженедельным обновлением, то
за три года работы системы накопилось бы = 52*3*40_000*0,3 +40_000 = около 2млн. позиций... из которых рабочих было бы по-прежнему 40тыс. КПД хранения 2%... Уже нравится. :)

Кот Матроскин Есть таблица товаров поставщиков с ключом "Артикул, Поставщик" и ссылкой (0..1) на таблицу наших товаров. Тоже никогда ничего не удаляется - только добавляется и обновляется.
... то есть КПД хранения такое же, а с учетом того, что у меня было 10 поставщиков (правда меньшего размера), то объем тут вырастает раза в три... около 6млн записей. Это раз. Нравится ещё больше. :)
... у Вас принят "обратный" подход. Если у меня по таблице синонимов связка симметрична, то у Вас по товару поставщика можно найти ваш товар, а вот обратно - надо искать (хорошо что по внешней ссылке)... скорее минус чем плюс...
... как будет добавляться товар Поставщика БЕЗ артикула, если он входит в определение уникального ключа? Не въехал. Пояните плиз. Подозреваю - никак. То есть с поставщиками без артикулов работать или сложно (надо придумывать за них) или совсем невозможно. Если это так, то с представленной системой сравнивать просто нельзя. Нет функционала.

Кот Матроскин Есть таблица элементов заказа - ссылка (1..1) на таблицу наших товаров.

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

Кот Матроскин"зеленая шапочка" поставщика связана с "фиолетовой" нашей товароведом 1 раз ,
и исправит ли ошибку поставщик в прайсе или нет - нам все равно.

перечитайте моё описание ещё раз внимательно. У меня не было снабженца, в смысле совсем не было. Как штатной единицы. Всю привязку "тот же самый" осуществлял полу-автомат. Самостоятельно (это те самые 10-15минут его работы, если он принимал решения сам на 3-5тыс. позиций... и без каких-либо артикулов и штрих-кодов (много их было в 97-2000гг, ага)

Кот МатроскинПри приемке в записях поставщиков меняются флаги "наличие"( + меняются еще какие-то поля, если они изменились у поставщика ). На основании этих флагов (и возможного остатка на складе) определяется, активен ли наш товар. На основании (возможно изменившихся) цен поставщиков и цен складских остатков - меняется цена нашего товара, делается запись в историю цен.

это понятно... склад он и есть склад... к вопросу отношения не имеет.

Кот Матроскин... поскольку наш товар не меняется в процессе - элементы заказов выглядят тоже однотипно, отличаясь лишь количеством и ценой.

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

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

Все таки, осталось непонятным: в случае переименования товара поставщиком - как будет происходить "процесс"?
Шаг1: на склад приняли зеленую шапку по артикулу1
Шаг2: создали свой товар шапка зеленая
Шаг3: пришел тотже артикул с другим названием... если записи НЕ удалаяются, то этот товар тупо перезапишет (артикул входит в ключ) запись о зеленой шапке. Была шапочка зеленая - стала фиолетовая.

... Ни на каких внешних ссылках ЭТО не скажется... то есть как смотрел ваш товар "шапка зеленая" в эту запись, так и смотрит теперь, только там "шапка фиолетовая"... впринципе можно и так.

Но! А теперь смотрите внимательно за вашими ручками : старые заявки поставщикам ... угу при перепечати (ихний бух запросил сверку)... стали поставками шапки ... упс. "фиолетовой". И? :)
... или поясните, не вижу как это "обойти можно"... товар по артикулу - ТОТЖЕ САМЫЙ...
...
А чего там описывать? При наличии произвольной связи М:М (синонимы) мойТовар - Поставленный(все равно от кого) и наличии правил работы с Поставщиком - распределить заказ оптимальным способом автоматом - достаточно простая задача. Простой градиентный спуск.
... часто товары одного поставщика объединялись у меня (например память noname производителя... туда же втыкался и якобы фирменный Самвсуньг, который у меня не проходил ряд тестов на качество... Китай он и есть китай). Понятно, что это делалось уже вручную... но тоже "однажды" (далее автомат помнил об этом).

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

у меня - работа с прайс-листами (поставщиков, своими) - отдельна и динамична (правка, удаление и т.д.)
, а вот работа с документами (аналог 1С - проведенный документ) - жестко фиксирована.
перенос Сущностей из одного состояния в другое - копированием (и соответственно своим ссылочным ОЦ).

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