Здравствуйте. Может кто уже делал периодическую выгрузку журнала регистрации в базу MS SQL средствами 1С? Поделитесь опытом, насколько уменьшилось время фильтрации и насколько увеличился объем базы? Как решали хранение, в регистре сведений, в одной отдельной таблице или как-то нормализовали и создавали несколько таблиц?

(0) Зачем это?...
У меня, например, база 90Гб, журнал регистрации - 82Гб.
Представь что будет, если я его запихну в базу. База 170Гб.
Ради чего?.... Какой смысл от журнала в базе данных?
А есть еще базюка, где журнал, настроенный на регистрацию всех событий, прирастал по 10 Гб в неделю.
И всё это надо архивировать, обновлять индексы и статистику, переиндексировать...

Решения такие конечно существуют, но ИМХО, бред и баловство бестолковое всё это.

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

(2) Это я понял. А оно стоит того, чобы пихать это всё *авнище в базу данных? Вплоть до того, что объем таблиц, занимаемых журналом со временем станет больше объема, занимаемого всеми остальными реально полезными и нужными данными?

Покури как в ДО логирование работы пользователей сделано.
ИМХО этого достаточно.

Или так или бигдата на стеке ELK

(0) я делал.
Время фильтрации с отбором по одному объекту практически не изменилось. Но время фильтрации с несколькими отборами и всякими нечеткими поисками по строке увеличились на космические порядки. Ну и плюс мы к этому прикрутили СКД с ее отборами, чего штатный ЖР не умеет.

Объемом базы не заморачивался - все хранилось в отдельной скульной базе. Ну, она какой-то там размер имела и как-то там росла. Насрать.

Хранение - в отдельной БД на скуле. Без прослойки в виде 1С. Коннекты к ней - по АДО ДБ. Дело было на 8.2, внешних источников тогда не было.

Нормализовали неистово. До самого до победного. И индексировали, выпучив глаза до щелчка.

Давно дело было, сейчас бы такой хернёй вряд ли стал заниматься, а взял бы Elastic Search.

вот держи http://catalog.mista.ru/public/862310/