Суть - база "долгая" и не подлежит свертке
медицинская
в день до 1000 документов одного вида
несколько тысяч записей в регистр

конфигурация подлежит постоянному совершенствованию
и вот добавил реквизит в документ - и при обновлении сидишь и смотришь на реструктуризацию таблицы в пару миллионов записей, а базе всего-то 10 лет

какой выход может быть?

Виселицу не предлагать?

Традиционно базы для медиков не делают на реляционных бд

(2) обрадовал

Ну , купи корп версию - там вроде реструктуризация фоновая - хотя наверное все равно с блокировкой таблицы

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

(5) эти механизмы в типовых называется "Дополнительные реквизиты и сведения"

Там данные в объектах хранятся

(7) сведения вроде-же ПВХ + РС

Да наверное действительно проще регистры сведений и потом бежать)) от воплей регистратуры. Поддерживать работу неподчиненых регистров ещё та забава ))

(0) "и смотришь на реструктуризацию таблицы в пару миллионов записей"

Там делов на пару минут

(10) на сегодняшний момент доходило до полу-часа

Пол часа? Да вы шутите, эту сущие копейки. У меня обновления долге идут...

(11) А вы что каждый день добавляете реквизиты?. Раз в месяц запланируйте на час тех работы. Если такой возможности нет, то извращайтесь:) и потом отбивайтесь от регистратуры..
Понаделайте загодя реквизитов типа строка, при необходимости добавления нового реквизита используйте их, в строку пишите УИД, и со значениями через УИД работайте:)

(11) полчаса? Раз в месяц остаться после окончания рабочего дня и выполнить все, что требуется с базой - такой вариант не рассматривается?

(13) почему бы нет
у меня больше 10 видов документов одного типа (мед запись специалиста)
сегодня в один добавил, завтра в другой

(0) Когда процесс будет занимать многие часы, тогда можно задуматься. А так - ночью точно можно час выделить. Вряд ли у вас работа 24/7.

(15)  - сразу в рабочую что ли. лично у нас с начало в тесте доработки делаем пользователи тестируют, а в запланированиое окно - переносим доработки в рабочую базу.

(0) использовать новый механизм обновления
https://wonderland.v8.1c.ru/blog/optimizatsiya-restrukturizatsii-bazy-dannykh/
https://its.1c.ru/db/v8311doc#bookmark:adm:TI000000527

ну и стараться "доп.реквизиты" не изменять!

Пара миллионов записей обновляетс пару минут.
Ок если это документы, то может пару десятков минут.

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

так платформа же корп есть для таких случаев

корп делает ALTER TABLE  - на порядки быстрее чем типовой механизм

КОРП сейчас - сверхдорогостоящая роскошь.
"Продление срока действия РКЛ для возможности использования лицензий 1С КОРП
Для получения права на обновления версий платформы "1С:Предприятие 8 КОРП" и ИСПОЛЬЗОВАНИЕ, необходимо приобрести Расширенную Корпоративную Лицензию (РКЛ), ежегодный платеж за которую составит 15% от рекомендованной розничной стоимости всех лицензий уровня 1С:Предприятие 8 КОРП (серверных + клиентских) по действующему прайс-листу фирмы "1С", но не менее 300 000 рублей", http://www.online-ufa.ru/content/articles/upgrade-licenses-1c-from-prof-to-corp/
Нет, если финансы позволяют, то конечно...
Серверу, на котором работает 10-и летня база, тоже лет 10?

Maxdop=0 не?

https://its.1c.ru/db/metod8dev#content:5945:hdoc

Как уже сказали, человеческий выход только в КОРП реализовали.
В ПРОФ создается копия таблицы.
Пол-часа и пару миллионов записей - это еще цветочки. Плюс есть некоторый запас на апгрейд/оптимизацию железа.
Когда действительно прижмет - остаются суровые варианты с подменой конфы и ручным добавлением колонки в БД.

(0) Создать копию таблицы, перенести в нее данные из исходной (insert into ... select). Исходную очистить (truncate table). Выполнить реструктуризацию. Перенести данные обратно. Заполнить новую колонку данными по-умолчанию (если надо). Готово.

(2) много примеров нереляционных БД?

(0) Версия 8.3.14

Ускорено выполнение реструктуризации информационной базы при использовании СУБД Microsoft SQL Server и IBM DB2.

Реально побыстрее стало

(27) + 100...

(22) не путай реструктуризацию на сервере, доступную и в Проф, с механизмом фонового обновления

(31) разве алтер тэйбл в профе есть?

(32) а где написано что нет?

(27) Тогда уж переименовать исходную, создать новую со старым именем и полной копией структуры.
Собственно все тормоза при реструктуризации из-за этого переноса данных.

(11) Это быстро еще.....

(11) Ахаха.. когда за ночь не будет проходить, тогда начинай беспокоиться.

(34) +1. Написал свой пост и тоже об этом подумал, так быстрее в 2 раза будет))

(34) когда их сервер приложений переносит почему то пачками топ 100 или 1000  при
этом уходя в себя с опросом служебных таблиц

(0)
1с8 при реструктуризации создает копию таблицы и копирует в нею данные порциями по 1000 записей.

на последнем этапе таблицу удаляет , копию переименовывает в оригинал.

копирование по 1000 записей задерживает реструктуризацию.

поэтому напишите ddl триггер, который сразу переименует основную таблицу в копию , а копию в основную таблицу.

Был какой-то финт ушами, с созданием промежуточной пустой таблицы с новой колонкой, поищи в гугле.