Дня доброго.
Есть дилеммка.
Надо удалить из регистра сведений набор записей. Размером 50-5000 записей.
Удалить можно 2 способами:
1) В цикле, по одной записи, по индексированному измерению.
2) 1 раз, набором, по неиндексированному измерению.

Регистр гигантский (миллионы записей).

Блокировка регистра значения критичного значения не имеет. Ну, будет заблокирован, не страшно, пишется он фоновыми и рег заданиями, если запись не удалась - запишется через 3 минуты еще раз.

Замеров сделать не могу, регистр пуст.  Конечно, можно забить синтетикой, но лениво пока.

Еще есть идея - если количество записей меньше, мммм, 100 - цикл, иначе - набор.

> регистр пуст
> Регистр гигантский (миллионы записей).

Вы уж определитесь

Озвучьте задачу с самого начала. Может там и регистр не нужен...

(2) Простите, не до конца расписал ситуацию. На данный момент проектирования системы - он пуст. Через месяц промышленной эксплуатации он будет содержать миллионы записей.

(4) Глупый регистр. Он не нужен.

Если нет индекса то отбор не установить. Даже если и ухитриться сделать delete from ... where реквизит то будет fullscan. Явно неправильно спроектировал что-то...

Зачем регистрировать миллионы записей, чтобы потом их быстро удалять? Автор — плохой архитектор систем.

(4) 2...3 ляма для регистра сведений - это не много даже если в измерение запихнуть строку в 1000 символов...

(8) + большой - это года под 100 лямов...

(8) При самом пессимистичном сценарии он будет увеличиваться на миллион в день.

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

Очищаться - нуу, даже не знаю, все, что старше 3 лет, возможно. Пока не думал, надо советоваться с методистами.

Расскажи о регистре подробнее чтобы было понятно и что за измерения, по каким измерениям предполагаются отборы и по каким(ом) измерениям удаления и зачем удаления?

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

(14) бред...

(14) Справочник - бред. А вот про обновление статистики - есть мысль как то автоматом запускать job после массовых обновлений регистра.

я склоняюсь к стабильному по скорости и прогнозируемому варианту - удалении в цикле.

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

и т.д.

но конечно я тонкостей задачи не знаю...

(17) Да, тоже сейчас это осознал понял.
Чертовы стереотипы 1С :-)

(16) для твоей задачи не имеет смысла запускать статистику чаще 1 раз в сутки....

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

Стереотип: "Видишь Отбор и НаборЗаписей - используй его, не думай!"

(19) Стоит. Когда у меня еще была база с синтетикой на миллионы записей, изменение 100 тыс записей рушило весь красивый план запроса до обновления статистики.

(21) Но это немного другая проблема.

Кто нибудь запускал процедуры SQL из 1С через ВнешниеИсточникиДанных, например через:

ВнешнийИсточникДанныхМенеджер.<Имя внешнего источника> (ExternalDataSourceManager.<Имя внешнего источника>)
<Имя функции> (<Function name>)
Синтаксис:

<Имя функции>()
Возвращаемое значение:

Тип: Произвольный.

Описание:

Вызывает функцию внешнего источника данных.

Доступность:

Сервер, толстый клиент, внешнее соединение.

я сегодня разбирался с файловыми базами 7.7, ну и перетаскивал, все что в каталогах было растаскивал по смылу...


в одно из каталоге который хранился в базе (и бекапился) нашел 600 000 документов, сканы, и т.д. Вот где я репу чесал :)

а Вы регистр большой :)

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

(25) Тоже вариант, только я не знаю, как его делать. Но узнаю.

(24) > в одно из каталоге который хранился в базе (и бекапился) нашел 600 000 документов, сканы, и т.д. Вот где я репу чесал :)

И в чем была проблема?

(27) Каталог долго открывался в проводнике.

Можно ещё попробовать обновлять записи вместо удаления и выключить активность. Посмотреть может активность в индексе

(27) зачем это лежало в каталоге файловой 7.7... при наличии специального сервера для документооборота

(29) Активность есть только у РС, подчиненных регистратору.

хз. у меня файлов в 10 раз меньше. 60 тысяч. тоже в каталоге.

+(32) сканы документов и картинки незачем хранить на серведе документооборота.
правда я функций сервера не знаю. однако мне нужно обрабатывать свежие файлы: паковать их и отсылать на сайт.

(31) да она по моему у всех есть по умолчанию в физических таблицах. А 1с всегда фильтрует по этому полю. Не факт для 8.1 было так, сейчас не знаю.

(0)
А это обязательно делать в 1С? Какая функциональная нагрузка у этой таблицы?

Неиндексированных измерений не бывает. Бывает отдельный индекс по индексированным.

(26) >> Тоже вариант, только я не знаю, как его делать.

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

(35) "А это обязательно делать в 1С? "

Без разницы, в чем это будет.
Разница в том, что вне 1С 2-ой некластерный индекс для данного измерения, по которому строится отбор можно сократить, не включив в него остальные измерения, но это сомнительное достижение, чтобы отказываться от "легкости 1С".

Это - коробочное решение, а ВнешниеИсточникиДанных требуют заморочек с подключением, которые ниасилят простые пользователи.

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

Интересно было бы узнать все же структуру этого регистра и его предназначение. Если абстрагироваться от 1С

(4) Я бы не стал пихать такие объемы в 1с. Какая информация там должна содержаться? Нужна ли привязка к объектам 1с? Возможно, стоит задуматься о внешней БД. Например, на MS SQL развернуть свою базу. MS SQL потянет практически любые объемы.