онфигурации для работы с большой базой?
Платформа 1С v8.3
1.  Drivingblind  190 15.10.19 12:30
Здравствуйте. Есть одна большая база УПП, в которой необходимо настроить работу нескольким специалистам. Работа в УПП ведется с незапамятных времен. Развернуть dt на локальном ПК нет возможности, т.к. в развернутом виде база весит 100+ГБ и работает очень медленно. Выгружать сам cf-файл без данных, зачастую, неудобно и ненаглядно, т.к. необходимо запускать отладку.
Подскажите, пожалуйста, как в подобных случаях организовать коллективную разработку? Есть ли какая-то возможность настроить хранилище конфигурации более оптимально?
Заранее спасибо за ответ!

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

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

Вангую, например, что подготовка к захвату объектов в хранилище легко может занимать пару часов времени... ну или что-то такое

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

(0) Перейти с хранилища на гит

Делаем так.
1. Делаем копию раб базы.
2. В этой копии сворачиваем так что база уменьшился до максимуму оставить данные чисто для теста.
3. Из этой маленькой базы сделать хранилище.
4. Всем раздать копию базы, каждому кодеру в качество ответвления хранилища.
5. Кодить и обновлять базу  маленькую и после этого ее объединять с рабочей базой и все.

По моему уже выше об этом сказали.

(5) рецепт хороший, только именно хранилищу конфигурации как-то глубоко безразлично количество данных в базе данных

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

абсолютно пофиг из какой базы сделать хранилище конфы - это только хранилище конфы
И размер хранилища, проблемы хранилища - это только размер конфы и проблемы конфы

(0) "настроить хранилище конфигурации более оптимально" - а чем вас текущая настройка не устроила? Долго захватывает и помещает в хранилище? Такая проблема бывает из-за кэша, чистишь его и снова быстро все работает.

(6) (7) Вам же говорят  база большая и нет места на диске у разрабов. Вся проблема в этом.
Вот у меня база розницы 200 ГБ база УТ 250 ГБ еще база КА2 120 ГБ.
Пока места хватает у меня. Но попросил доп диски.
Если бы у нас не хватало наверно также парились бы.

Тут либо компы разрабов усиливать или работать на урезанной базе меньшим объемом и более менее шутсрее будет крутится.

(0) Никаких особо хитрых способов волшебным образом оптимизировать работу с хранилищем не существует.
Если проблема в размере базы, то возможны какие-либо вариации на тему с обрезанием базы при подготовке баз для каждого разработчика (по примеру из (5)). Но проблему размеров самой конфигурации это никак не решит. Захват и помещение всех объектов, когда это необходимо, например для обновления конфигурации от 1С, всё равно будет происходить небыстро.
У самого стоит УПП+БИТ-финанс 1.3/3.0 подключенная к хранилищу. Работает вполне себе с нормальной скоростью. Долго и муторно происходит захват/помещение при обновлении всей конфы. Тормоза при работе с историей хранилища (сравнении текущей конфигурации с версиями из хранилища). Но не могу сказать, чтобы это было совсем уж смертельно.

Вообще с трудом представляю себе организацию, имеющую УПП размером под 100Гб, у которой нет денег на отдельный сервер для разработчиков или хотя бы на отдельный(ые) диск(и) под разработочные базы.
База в 100Гб в наше время - это небольшая база.
В конце концов для сервера разработки не нужно какое-то сверхмощное железо, как для продуктива, на котором сидят сотни пользователей 24/7.
Для разработчиков важнее производительность их собственных компов.

(11) +1
У мен я вот:
Проц AMD Ryzen 7 PRO 2700 Eight-Core Processor 3.20 GHz
ОЗУ 16 ГБ
Диски 2 по 250 SSD 2 ТБ обычный диск

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

База 100Гб - это небольшая. Поставить типа "сервер" с NVME SSD на 4Тб и забыть о проблеме.

(13) "А базу для разработки напрямую к хранилищу подключать - это надо очень сильно хотеть себе проблем" - о каких именно проблемах речь? С чем сталкивались?

(14) В базе для разработки колбасишь как хочешь любые объекты, и не надо держать их захваченными в хранилище.
И наоборот - если в хранилище кто-то поменял реквизит, из-за которого будет реструктуризация на 3 часа - тебе можно это изменение тянуть не сразу со всеми изменениями, а потом.

(15) Странно. Сколько у вас разрабов  правят одну базу или одну конфу?
Как вы избегаете проблему того что одновременно двое зашли в один объект  и начали там менять код итп.?

(16) Никто не мешает захватить в хранилище нужные объекты и держать сколько требуется. Но разработку ведешь в своей базе, не привязанной к хранилищу.
У нас 2-3 человека, все в одном кабинете сидим.

(17) Нас было 3-4 а сейчас 2 человек не паримся на счет хранилища.
Хранилище дисциплинирует. И нет трудностей при обновлении или при захвате или при отправке

(15) по такой схеме работает подавляющее большинство команд на ERP, хранилища разработчиков на пустых базах, отладка на индивидуальных копиях уменьшенного по отношению к продуктиву