Всем привет!
Есть рабочая конфигурация, сильно переделанная розница, написано на 1С 8.1.
Есть необходимость загружать кучу всякой номенклатуры из огромных прайсов, периодически. Это нужно для сайта. Но вот куда загружать?
В самом справочнике номенклатуры этого не нужно, туда будем переносить только действительно требуемые товары, которые заказывает покупатель, чтобы не раздувать справочник. Но вот справочник всевозможных товаров из прайсов будет очень огромным. Вопрос: очень большой справочник будет создавать тормоза при работе с системой, если он не используется ни в каких документах и отчетах пользователей? Т.е. вся обычная работа розницы будет идти без учета его. Он будет использоваться лишь для перекачки нужных товаров в справочник номенклатуры и для выгрузки на сайт.
Можно сделать его вообще в отдельной базе, забацать обмен. Но обслуживание не удобное, в одной базе всё проще. Но вот не будет ли такой гигант мешать и тормоза создавать при работе, если он будет в основном лежать и просто занимать много места :)
База файловая, но SQL под это дело планируем

(0) топик ни о чем
100 000 номенклатурных позиций 8.1 пофиг

(1) несколько миллионов будет точно. Потому и волнуюсь, как лучше реализовать, в одной базе с розницей, или отдельную базу сделать для хранения всевозможных товаров

есть специльные движки сайтов которые позволяют сразу же на сайт все и загружать

ТрейдСофт например.
А автозапчастях миллионы. У нас кажется уже лямов 10 на сайте, а в базе 500к рабочей

у тебя ведь задача не только с 1С. а потом еще прикинь на сайт выгружать и там загружать. Вам нужно все это напрямую сразу на сайт и лить.
Движок сайта должен поддерживать.

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

Тут все в первую очередб зависит от движка вашего сайта. Который нужно ставить специализированно под большие объемы.

(2) храни в отдельной базе на сиквеле(ясен пень не 1С), таскай в 1С по необходимости

Мы уже давно думаем сделать чтобы обработка в 1С была по загрузке (например настройки хранила, юзер там настраивал и тд и тп) а все заливалось во внешку БД. причем без скуля.

Как раз для больших объемов. те интерфейс будет 1Сный а база внешняя

ProProg, спасибо за информацию.
У нас именно автозапчасти.
Сайтом будет заниматься другой человек, я не спец в этом. На мне только 1С, плюс выгрузка-загрузка с сайтом.
Насчет прямой загрузки спасибо, подумаем.
Я сейчас уже реализовал загрузку в розницу только нужных товаров. А сами товары хранятся во внешей базе, но тоже 1С-ной. Предполагалось в ней подобие базы TecDoc, из которой подтягивать нужные товары в свою розницу. Но разбор базы TecDoc пока не осилили, поэтому загружаем просто списки от поставщиков.
Но вот решили делать сайт и работать с прайсами. Это ещё огромный объем.

(10) >> Мы уже давно думаем сделать чтобы обработка в 1С была по загрузке, а все заливалось во внешку БД. причем без скуля.

А почему без SQL? Что за внешняя база тогда, если без SQL?

(9) А что, 1С на сиквеле такие объемы не потянет?
А я ещё думал такой справочник в рабочей базе розницы создать... Тогда что, вообще всё загнется? :)

(12) у меня сотр прогит на питоне профессионально. может любую базу суперскоростную накатать без использования СКЛ.

(13) мне кажется, просто обычная MSSQL база вполне подойдет. Лежащая на одном SQL серваке рядом с базой 1С.

причем даже без установки чего либо.
Мы уже давно используем некоторые вещи. У нас прайс 1 миллион строк загружается за 7 минут.
Да и думаем на над своим сервисом специальным.

Так это мы еще в 1С льем. Чо говорить если напрямую там будем все за минуту делаться.

(14) питон - язык программирования. База - она должна где-то размещаться. Что значит "может любую базу суперскоростную накатать без использования СКЛ"? Т.е. база не в СУБД Oracle например или MS SQL, а в каком-то своем формате? Или я чего не понимаю. Впрочем с языком этим не знаком, просто интересно.

(18) ну дык быстрее плоского файла ни один сиквел не работает =)

(18) у буржуем вагон бесплатных движков баз данных. нужно просто знать английский язык чтобы по их сайтам шариться и понимать что они все делают.
Я конечно тупой 1Сник, но у меня сотр какой мегамозг во всем остальном.
Что конкнретно он использует и тп я без понятия.
Но у него три монитора и он вечно где то там в прострациях.

(15) А что, сильно отличается обычная MSSQL от 1С на SQL?
База 1С лежит в своем формате на SQL-сервере, как и любая другая база. Но при этом значительно тормознее работает?

Насколько он мне говорил что да он может своб БД сделать без чего либо. со сверхскоростной скоростью.

(21) конечно медленне, в десятки раз
1С поддерживает целостность и нумерует элементы программно

(22) В общем я понял, вашим путем нам идти нельзя :) У нас нет такого мегамозга :)

ищите готовые системы, они уже давно есть.
Не вы первые работаете с интернет-магазином в миллионными товарами.
ТрейдСофт есть и другие. И стоят недорого.
прайсы, проценки и так далее. готовые базы данных с прайсами поставщиков. веб-сервисы.

(23) понял, спасибо. Создать внешнюю базу в MS SQL я смогу. Но нужна программа, которая будет закачивать в неё данные. Я смогу это делать только опять же из 1С, поскольку ни на чем другом не программировал уже около 15 лет :) Но думаю это на скорости не скажется, ибо писать буду напрямую в SQL, а то что из 1С, дак это тут не так важно наверное.

Но всё-таки интересно: даже если справочник в 1С не используется, но имеет очень большой объем (миллионы позиций), то из-за него всё-равно тормоза будут в 1С?

(25) ага, спасибо, надо изучать вопрос

(27) элементарно ватсон.
Миллион строк. в 1С у дока максимум 99 999 тысяч строк.
Регистрация цен в 99 999 строк попробуй провести.
А теперь попробуй провести 10 сразу таких доков.
Пусть даже если будет один документ.


Будешь подня сидеть проводить.


2) синхронизация. ведь прайс грузится не раз. поставщики такие каждый день обновляют свой прайс- наличие товаров, цены.
Каждый день надо 1 миллион синхронизировать при загрузке со справочником и регистрировать цены в регистре.


На этих двух моментах думаю дальше не стоит продолжать.

Я уж молчу про выгрузку этого всего добра в файл на сайт.

Нехватка памяти и все такое. Обмен с бух умирает если 150к объектов выгружается а тут про миллионы речь.

1С до сих пор остается системой сделанной для того чтобы ручками бухи вводили по 10 строк в документ.

в УТ11 нет нормального API для создания программно документов. куда не сунься чтобы какой то док сделать программно - надо мозг выесть.
150 реквизтов для заполнения.

в справочнике номенклатуры у одного 50 реквизитов.
А в автозапчастях нудно например все го три - артикул, наименование,производитель.

(29)
>> Миллион строк. В 1С у дока максимум 99 999 тысяч строк.
Дак я ж говорю, что справочник номенклатуры отдельно существует, в него будут грузиться только нужные товары. А все остальные будут сидеть в другом огромном милионном справочнике, который не участвует ни в каких документах. Это будет не справочник номенклатуры. Я понимаю, что периодически надо грузить в него позиции, производя синхронизацию, также нужно делать связь с сайтом. Но вопрос тут чисто теоретический, если допустим все эти синхронизации будут идти в нерабочее время, а в рабочее время этот справочник будет просто лежать в базе. В этом случае он будет создавать тормоза в связи со своим большущим объемом или нет?

И кстати по товарам предполагается ещё изображения хранить :)
Вот это я не знаю как во внешней SQL организовать, но 1С такое думаю не потянет

(31) (31) Делай базу на MSSQL, с помощью SSIS можно настроить загрузку данных.

В каком формате данные?

(33) Данные для загрузки в экселе. Но форматы файлов разные у разных поставщиков. В 1С это всё можно настроить, и грузить 1С-ной обработкой в SQL. А вот с помощью SSIS пока не представляю что и как, какие там возможности

(34) (34) Можно и обработкой из 1С в SQL грузить.
И использовать эти данные для создания номенклатуры в 1С при необходимости.

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

Пока всего 3кк товаров из внешних прайсов, а номенклатуры - только 50к. Полет нормальный.
Бывают прайсы больше 100к строк - проводим несколькими документами.
На сайт выгружаем только измененные цены/остатки + товары, которые пропали из прайса.
В рабочей бд храним только актуальные цены по каждому контрагенту, историю переносим в другую базу рег. заданием.
Пока не знаем, зачем, историю цен не используем.. Но вдруг пригодится.

Сама загрузка - из текстовых/эксельных файлов рег. заданием, настройки загрузки для каждого прайса сохранены в БД, манагеры сами настраивают. Однажды настроив только кладут в нужную папку новый файл с прайсом. А по некоторым "продвинутым" поставщикам прайс скачивается раз в сутки с их фтп или сайта автоматически.

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

Вообще самое занятное - это даже не загрузка, а сопоставление товаров из разных прайс-листов друг с другом. Понять, что это V-LINE 11 производителя NGK это тоже самое, что 5282 производителя НГК (оба варианта встречаются в реальных прайсах) - задача намного занимательнее.. =)
А потом еще закроссировать все это с аналогами от других производителей, попутно отсеивая весь бред, который встречается в загружаемых прайс-листах (неверная связка артикула и производителя) - вот этот механизм сейчас дорабатываем.

У нас схожая задача, вынесена в отдельную базу. Прайсы приходят раз в месяц, за полгода в таблице уже 7.5 миллионов записей. Это так называемая куча в которой все изменения цен. На основании этой таблицы обновляется таблица с актуальными ценами, и всеми сопутствующими реквизитами, для создания элемента справочника Номенклатуры. Т.е в любой момент пользователь может создать элемент справочника Номенклатуры, просто забив номер запчасти, автоматически подтянуться основные реквизиты с актуальными ценами.

(36) Спасибо за Ваш опыт.
Сопоставление товаров дело конечно сложное. Автоматически грузим приходы, тоже писал обработку.
Но у нас была идея иметь в отдельной базе все запчасти, взяв их из TecDoc, периодически обновляя. Но не осилили. Но идея иметь номера всех запчастей осталась :) Т.е. если даже в нашей базе нет товара по нужному номеру, то сам номер по идее должен быть, чтобы по нему выйти на аналоги, которые есть у нас в базе.

(37) >> Т.е в любой момент пользователь может создать элемент справочника Номенклатуры, просто забив номер запчасти, автоматически подтянуться основные реквизиты с актуальными ценами.

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

(38) ТекДок - это хорошо, но там есть не все, чем мы торгуем, и не все что там есть - актуально.
У нас на сайте при поиске по артикулу аналоги подтягиваются из двух источников: 1 - текдок, 2 - наша база кроссов.
Свою базу кроссов (которая в 1с) мы стараемся пополнять из оригинальных каталогов производителей, но таких у нас пока мало. + по новым товарам менеджеры что-то руками кроссируют.

Была тоже мысль подгрузить в 1с базу ТекДока.. Даже веб-программист нашел где-то поломанную годичной давности, которую уже в удобный для загрузки формат преобразовали. Потом подумали и решили, что не нужно нам это счастье в 1с.

Сейчас в 1с хранятся только те коды, которыми мы торгуем (или которые встречаются во внешних прайсах) + коды из подгруженных каталогов + коды из подгруженных кроссов.
А просто все коды текдока, которые никак не связаны нашими товарами - нам вроде и не нужны в 1ске.
А на сайте все и так есть.

(41) У нас веб-прораммисты не смогли сайт на ТекДок завязать, не знаю что там не получилось. Знаю только, что в SQL-базу этот ТекДок перегоняли, чтобы сайт уже с этой базой работал, и похоже запутались в структуре ТекДока

А по количеству записей..
у нас сейчас примерно 2кк уникальных кодов и 3кк товаров из внешних прайсов.

Отчеты по 3кк актуальных предложений летают очень шустро.

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

(41) Наши веб-программисты тоже не напрямую к тек-доку обращаются, в через апи linemedia. Там все тоже не очень гладко, но наши подстроились и работают.

(43) >> апи linemedia
нашел сайт linemedia, надо поизучать что они предлагают

(39) У нас обе базы на mssql, клиентская часть на c# wpf
+ поднят API SOAP для взаимодействия с сайтом.