Всем доброго времени суток.

У нас 1с 8.1 УТ 10.3 есть 5 складов один главный. С главного на другие склады каждый день отписывается товара тысяч на 100 - 300 на каждый склад в каждом перемещении около 50 позиций. Перемещение осуществляется так. Главный создает перемещение и указывает склад получатель виртуальный склад которого физически нет но есть в программе. Т.е. товар списывается с главного но еще не приходуется на второстепенный. Когда товар приезжает на второстепенный они на основании этой накладной, открывают новую т.е. создают копированием новую накладную. Указывая склад отправитель этот виртуальный а получателя свой. Вопрос в следующем сильно ли уменьшиться размер базы если скажем они не будут создавать копированием новую накладную которая оприходывает им товар на склад а просто по приходу буду менят этот виртуальный склад на свой?

Всем заранее спасибо.

(0) размер базы не измениться

(0) А если режим работы с базой серверный, то каким образом определяется "размер базы" в вашем случае?
И в каких измерениях будете смотреть, что в самом деле "сильно"

(1) т.е. разницы не какой что отписывать сначала на один склад а с ней на другой что на прямую. 1с все равно 2 или 1 документ по этим позициям номенклатуры дубляжа не будет ?

(3) очень несущественным будет уменьшение "объема" за день... сначала посмотри какие таблицы базы самые пухлые, а потом уж думай

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

(5) Понятно спасибо. Вот как раз это и хотел узнать. Что не стоит менять.

(4) А как посмотреть эти самые таблицы? вобще где их смотреть? Просто за год база выросла на 4 гигабайта. А до этого за 2.5 всего на 4.

>>4 гигабайта
бугага... у нас под 100 гигов, и пофиг
>>А как посмотреть
На скуль зайти, тыкнуть по базе - Отчеты - Топ 100 таблиц

(7) так вот именно у меня файловая )))

(8) ну скоро на скуль перелезать придётся таки

(9) вот этим и занимаюсь щас. У нас РИБ. На одном филиале поставил скул postgres 9.0.3 1с 8.1.15 а сам компьютер Атлон 3200 1 Гб оперативы че то тормозит в такой связке. Не пойму почему. Удалил postgres опять в файловый вернул все быстро заработало почему так может тормозить?

>>1 Гб
Ну смешно же, ей богу....
Вобще клиент-сервер как правило производительность не увеличивает, паралелизм да, и то не постгри а скуль, для постгри надо переписывать

(11) в смысле переписывать?

(12) на управляемые блокировки

(11) и какие минимальные характеристики железа чтобы база в 10 Гигабайт на postgres крутилась?

(13) хотя бы где про них посмотреть можно ?

(14) хз, но полгига у тебя только винда съест, + постгре съест, + сервер 1с съест и т.д.

(15) хотя может и не надо, в файловой же работаете

миним 2 значит

?

(0) Ордерная схема перемещения не подходит (без виртуального склада)?

я так понял управляемые блоки это разделение транзакций, но зачем мне это ?

(18) ХЗ. сам подумай сколько памяти сожрёт всё что наставишь на сервак. сколько юзеров? серв 1с тоже жрёт немало

(21)> (17). не парься, если на файловой блокировки не мучают - постгри так как она работает

(22) Так вот именно что это не сервера, 5 складов везде по 1 компьютеру на которому работет 1 пользователь + главный сервер в офисе

(23) А если скажем такая ситуация когда будут делать выгрузку и одновременно будут проводить накладную, ошибки не будет?

(23) на файловом то все норм он просто выдаст что нельзя провести документ и после окончания выгрузки которая идет максимум минуту, все проводиться

чот я не понял, ключи на сервера 1с покупаете?

(27) ага, так уже было до меня

(27) стой какие на сервера

(27) просто один узел это комп с XP на ней

с одним пользователем

скажи лучше по поводу 24-26 то что я написал меня уж тревожить стало что вся база полетит если скажем будут одновременно выгрузку делать и проводить документы

(32) на время выгрузки встанет даже на скуле, при обменах блокируются таблици изменений, будет так же как и сейчас у тебя, подождёш пока обмен завершится

(30) дак файловый вариант то? где постгри то?

Вобщем у меня сейчас один сервер на котором 2 оператора в офисе работают и 5 складов которые делают выгрузку на главный сервер на склад XP и один пользователь и везде файловый вариант, хочу везде поставить постгрес. На одном попробовал тормозит

>>везде поставить постгрес
тогда купи ещё 6 ключей. Пиратсво зло

вот хотелось бы последний вопрос у тебя спросить минимальные требования я так понял для пострег это 2 гигаб оперативы? а проце Атлон 3200 подойдет?

где вобще можно посмотреть эти требования ?

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

делай бэкапы главно ежедневно

(39) Да а когда полетит и не смогут документы проводиться вот мне веселие будет это же все склады встанут сразу

(40) А разве нельзя главную базу востановить из филиалов? если у меня так полный обмен идет? И наоборот филиалы восстановить из главной

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

начали за здравие, а все свелось...

(38) хотя бы в рекомендациях 1С посмотри
http://v8.1c.ru/overview/recomendations.htm

(42) в смысле встанет база не пойму?

(45) Ограничение файлового варианта работы баз 1с: не более 4 Гб на таблицу БД. при превышении этого порога - база в файловом варианте перестанет быть рабочей впринципе

(46) ну в принципе она рабочая, но в ней нельзя создать новые записи в тех таблицах, которые уперлись в 4 гига

после этого можно "свернуть" и работать дальше

(48) хмм а это уже интересно, просто сделать бекап сохранить его куда нибудь, а свернуть скажем на первое число базу.

А разве в 8 можно сворачивать где это находиться?

А как быть с филиалами или если я сверну главную базу то и на филиалах тоже свертка придет с выгрузкой?

А можно скажем свернуть базы на складах, а в офисе оставить полный вариант базы и только там поставить SQl ?

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

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

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

52+ кстати, перечитал топик и вижу, что, вообще говоря, схема работы складов в периферийных базах с остатками для формирования заказов на перемещение может включать в себя просмотр актуальных остатков центрального узла. Тогда тем более, имеет смысл актуализировать остатки центрального склада документами технологических инвентаризаций, если общий состав номенклатуры достаточно обширный, то польза от этого будет наверняка.

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

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

Мда... И тут Остапа понесло (с)