Доброго.
У нашей дружественной организации, есть отраслевая конфигурация.
Но они на сегодня столкнулись с проблемой. Большие задержки по обработке документов, отчетов и прочего.
Мы свое время, глянув на эту реализацию, прогнали несколько тестов, сказали нафуй. И сделали отдельный блок не на 1С. На 1С мы не осилили. Сейчас надо сделать на 1С.
У них все это сделано на одном регистре сведений, который еще и подчинен регистратору, девять видов документов. На текущий момент, при общем размере БД в 50 гигов, только этот регистр 14 гигов. В общем, печально все.
Структура регистра такова.
Измерения
- Марка – тип строка 160
Ресурсы
- Упаковка - тип строка 120
- Справка – тип СправочникСсылка.алкКлассификаторСправокАиБ
- АлкогольнаяПродукция – тип СправочникСсылка.алкКлассификаторАлкогольнойПродукцииЕГАИС
- Организация - тип СправочникСсылка.Организации
- ПунктРазгрузки - тип СправочникСсылка.алкПунктыРазгрузки
- ОтметкаВыбытия – тип булево

На текущий момент обсуждается вынести это в отдельную базу. Но надо как-то оптимизировать. Если перенести 1 в 1, задница все равно догонит.
Объемы будут только расти.
В общем, рад любой идее.
Может это регистр как-то сжимать периодически.

1. Не хранить данные в документе, прямая запись и чтение из регистров.
2. Для максимально возможной быстрой записи в регистр (прямой инсерт) использовать запись через НЗ в режиме загрузки и без замещения.

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

ХранилищеЗначения? не, не слышал

(1)
Так данные в доке вроде и не хранятся.
Меня больше чтение интересует.

(0) кт-ая конфа она да, такая..
:)

(4) чтение ? Может запись в этот монстр, не ?

(2) Не хотят. У нас голый скуль и клиенты на С#.

(5) Да блин. Догнали меня они все же. Как я не хотел с ней связываться.

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

(6) Запись тоже нужна. Но запись пока вроде терпит. Но если есть мысли, то буду признателен.
У них начались проблемы с ТСД, тормоза.

НАверно база пухнет от того что измерение строка.
Нельзя марку и упаковку справочником сделать (пусть чисто  с одним наименованием)?

(9) С упаковкой согласен. А марка какой смысл? Она уникальная. в 1С ссылка гуид, особо ничего не выиграем.

(9) присоединяюсь

(12) ссылка намного короче. чем строка 160, не говоря уже об индексе

я не спец, но мне сомнительно что в ресурсах ряд то, что ябы поставил в измерения.

на фузину еще можно перейти. заодно стрясешь денег с фузины за обчуение что к чему.
потом поделишься.

(14) Ваша правда, 32 символа против 160. Плюс марка, в этом регистре накопления, не уникальна.
Каждый док пишет ее.
То бишь у меня, в идеале, минимум две записи.
Приход и расход.
А если ее туда сюда погоняли, с десяток может быть.

(16) Вот только про фузину не надо. Я закивал удочку боссу. Он сказа по 1с спецы если что есть, по С шарпу тоже найдем. А эту хрень не надо. кто ее пилить будет если чего.

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

http://catalog.mista.ru/public/527518/

(0) "Измерения - Марка – тип строка 160"
Сделать справочник Марки, в нём наименование длиной 160, а в регистре измерением ссылку.

Хорошо если сделать регистр независимым, то как сохранить историю?
История движения марки нужна.

ИМХО все это надо запихивать в регистр накопления и измерением - ОтметкаВыбытия – тип булево = количество,на остатке - 1 есть 0 выбыло, тогда регистр будет закрываться, и регистр сведений так и будет пухнуть по сути - справизник же

(21) ответ же очевиден - в измерение ссылку на док

измерением  = ресурсом

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

заместо ОтметкаВыбытия , число с 1.0,  0 - ттн поступила. 1 - акт подтвердил ттн, -1 - товар продали/списали/переместили..

В любой момент можно грохнуть записи лишние, те что на остатках нет. Есть вся история, есть все остатки.

Объясните, почему марку обязательно справочником делать. Один черт же будет сначала поиск элемента справочника по наименованию с использованием почти такого же индекса, как и для регистра.

>> сделали отдельный блок не на 1С. На 1С мы не осилили. Сейчас надо сделать на 1С.

Внешние источники данных не осилили?

>>На текущий момент, при общем размере БД в 50 гигов, только этот регистр 14 гигов. В общем, печально все.

у меня по 120 гиг регистры - все нормально. Просто индексы может регулярно пересчитывать и план запросов сбрасывать?


Марку в отдельный справочник можно выделить - но я не вижу никаких замеров по производительности. Возможно просто сделали подключение через ODBC и этот ODBC объект каждый раз создается да еще и в переборе строк каждый раз идет подзапрос.


Без кода не камлаю.

(26) Так это уже регистр накопления получается.

(29) итогов нет и..почитайте за разницу, что ле

(29) Нет. Измерение по марке идет. Ключ перезапишеться - все данные перезапишуться.

(28)
1. Нам скорости не хватило. У меня сервер хороший десктоп. Я уже за 500 гигов ушел. Но у меня ушедшая марке в архив сбрасывается. Активный объём 10 гигов.

2. Обслуживание базы сделал как 1с рекомендует.
Статистки раз в сутки, реиндексация раз в неделю.

(30) Ну логика работы получается.

(32) 1С ясно дрыщевый сервак, на котором Майнкрафт и bitcoin вертиться вдобавок.

Пересоздай таблицы хотя бы и проверь профайлером от 1С чего у тебя там лочиться.

Убери все индексы с регистра кроме измерения с допупорядочиванием.  Посмотри какие запросы идут к регистру - 95% код в проведении кривой или вообще в подписках какой-нибудь умник допроведение поставил.

(32) Случайно у вас к регистру обращение производится не запросом с ПОДОБНО по измерению?

Да хрен его знает. Это отраслевая конфа, я только засел ее ковырять. Она еще и с СЛК защитой.
И пилить мне ее точно не разрешат.

(36) И сколько платят? СЛК всегда можно расковырять, если совсем код в dll не перенесли.

Офигеть. Круто... Народ обсуждает методологию, не зная вообще ТЗ.
Как можно вообще о чем-то говорить, не зная ни для чего этот регистр, ни какие по нему строятся отчеты, ни какие данные, когда и куда берутся?
Может там надо десяток маленьких регистров делать причём разных - накопления (остатков и оборотов), сведений (обычные и периодические) и расчета (с периодами действия и без).

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

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

>>А через пару лет всё встанет колом.

Гораздо быстрее.

>>слишком много ресурсов связаны с маркой.

Если марка это GUID - никакого смысла делать отдельный справочник.

(38) Ну есть какие общие-то практики проектирования.