Расскажите, пожалуйста, какой профит?
К примеру, добавил я реквизит, таблица реструктуризируется. Но оно бы работало и без реструктуризации. В чем смысл?

>>Но оно бы работало и без реструктуризации.
почему? Это изменение структуры таблиц.
У тебя в СУБД такой колонки в табоице нет, грубо говоря. Вот при реструктуризации - сами таблицы и меняет

(1) Почему тогда нельзя просто добавить новую колонку в уже имеющуюся таблицу в БД? Зачем именно создавать новую, а потом в неё копировать все данные?

(2) руки кривые потому что.

(2) можно
но без индексов учетная система загнётся

(4) А индексы тут каким боком??

(2) имхо просто сделано универсально... понять и простить (с)

(4) Индексы субд перестроит сама, я в неё верю.

Я могу предположить, что это сделано для дефрагментации, чтобы данные не были размазаны по файлу БД. Небольшой выигрыш в быстродействии.
Зачем может быть ещё?

(7) а она в тебе не верит

(7) а кто скажет субд что это поле надо индексировать? в какой именно индекс (кластерны и др)?

Вся структура таблиц меняется при реструктуризации. Все мелочи и нюансы, про которые люди тупо забудут, а железка не догадается

Я сильно отстал от жизни но помнится в заголовке файла писалось смещение в байтах или ещё в чём. Добавив колонку мы меняем это самое смещение и к каждому элементу должны приписать значение нового реквизита. Как тут без реструктуризации.

(11) Какая связь между копированием всех данных и изменением структуры таблиц?

(13) в 100% флюдорастическом топике связей нет и быть не может

как платформа работала так и будет работать

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

(12) отстал... на файловых никто не работает))

(15) Вот смотри. Если, допустим, ваять БД руками, то мы добавляем колоночки в таблицы, удаляем колоночки, меняем индексы как нам хочется. И СУБД там как-то что-то само с данными делает, и всё работает.
Но при такой работе для каких целей нам придется создать точную копию какой-либо таблицы и скопировать в неё все данные?

(17) я не разработчик платформы, но верю в МногоУважаемогоБорисаИСергеяНуралиева, не просто так они сделали именно эдак.
Или ты надеешся на мисте познать истину?
Моё имхо - в (6)

(17) а БД в твоем случае наделена магическими способностями?
Добавление поля в таблицу — далеко не тривиальная задача, особенно, если таблица большая.

(19) добавление то ещё ладно... а вот удаление типа из составного - тут никакая СУБД не проймёт, там же 3-4 колонки на тип составной

(19) В чем же нетривиальность? Вошел я в SQL Server Management Studio и легко добавил 3-4 колонки в любую таблицу.

Просто открой книжку по MSSQL и почитай как хранятся записи таблиц. И что происходит под капотом

(20) Сформулируем иначе, добавление поля (двух полей для ссылочного типа) в таблицу SQL средствами MSSQL занимает столько же времени?

(22) Т.е. суть таки в дефрагментации?

(24) скуль хранит данные постранично. каждая страница фиксированного размера... короче там это. нанотехнологии.

(25) Хорошо хорошо. И что? )

(26) и всё)
И чего к скули привязались? СУБД много разных поддерживается. Вариант с созданием новой таблицы - универсальный для любой СУБД

(27) А какие-то СУБД не позволяют тупо добавить колонку в уже имеющуюся таблицу с данными?

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

(29) Да, это разумно

(28) давай более сложные случаи, что за примитив с добавлением реквизита?

(31) Удаление 3х колонок от реквизита составного типа. Суть-то не меняется

(24)>Я могу предположить, что это сделано для дефрагментации
- совершенно верно. Плюс просто лишний раз шерстит базу 1с на предмет структуры таблиц, мало ли что там поломается...
(22)>Просто открой книжку по MSSQL
- и каким боком "MSSQL" к файловой реструктуризации? А она там есть.

В 1С решили, что надежнее пересоздать таблицу заново. Думаю - правильно сделали, иначе кривизна рук их программистов могла привести к тому, что при добавлении/удалении реквизитов что-нибудь плохое могло случиться с базой.
В 8.3 додумались до фоновой реструктуризации, но всё равно приходится всех выгонять для окончательного обновления.

(0) >>Но оно бы работало и без реструктуризации.

вспоминаю времена 7.7 помню умельцев которые базу обновляли копированием туда нового *.md - "а чо оно же работает)"

имхо суть в том что наша 1с платформа анализирует ту структуру данных что имеем и ту что хотим получить ну и принимает решение за нас...на эту тему еще можно вспомнить что у нас например явного описания типа переменных нет и т.д. и т.п. - 1с многое берет на себя))потому и 1с-ников за программистов не считают)

(31) во времена еще не совсем улета 1с в дебри Такси она сама говорила - реструктуризация нужна лишь для упорядычевания расположения талиц. Все.

(36) Жаль не сделают эту шляпу опциональной. База 100Гб реструктуризируется сутки. Утомила.

(35)>имхо суть в том что наша 1с платформа анализирует ту структуру данных что имеем и ту что хотим получить ну и принимает решение за нас
- это как все работает, объясните?
>явного описания типа переменных нет
- потому что хранится все не так явно.
>1с многое берет на себя
- много в платформе сделано "по умолчанию", причем замалчивание настолько секретное, что ЦРУ позавидует. Отсюда и 90% проблем и ошибок в 1С.

(21) а самолет тоже просто работает — сел и полетел

(37) галочку отключите

(40) У меня переход БП с 2.0 на 3.0.

(39) вообще, все базы так и работают - сел и полетел. И только 1с не может добавить "руками программиста" колонку в таблицу БД.

(41) так это опять прихоть/принудительно-добровольно 1С - все, как и с платформой.

(39) Паспортный контроль утомляет так же, как и реструктуризация. Но эту тему я подниму чуть позже.

*90% платформенных ошибок

(38) - это как все работает, объясните?
- много в платформе сделано "по умолчанию", причем замалчивание настолько секретное, что ЦРУ позавидует.
я в 1с не работаю и в "секреты" не посвящен))...а было бы интересно кстати в дебри залезть)но тут имхо мы где-то на грани лицензионнного соглашения балансируем)

(41)> У меня переход БП с 2.0 на 3.0.
- вы смелый. По-моему, проблема реструктуризации - далеко не самая главная будет у вас в ближайшие полгода. Даже не в сотне.

(46) потому и закрыто, что сами плохо понимают.

Поэтому начинают объяснять ".. вот SQL работает так.. блокировки... оптимизатор..."
Ты объясни, как работает 1С В КАЖДОМ КОНКРЕТНОМ случае, и что ожидать на выходе.
А про SQL можно у Микрософт все прочитать.

(49) У тебя с этим проблемы? Ты хочешь об этом поговорить?

(50) ты можешь?

(47) Не первый раз, сдюжим. Ещё б реструктуризация так не тормозила, было б куда веселее.

тема слилась. Пришёл ненавистник своего рабочего инструмента (1с), своей профессии и всеговсего что связано с нуралиевыми

(51) Я могу объяснить любое поведение 1с, которое меня затрагивает.
Но вот _тебе_ я ничего объяснять не буду.

тема слилась давно - лет 10 назад, когда в 1С пришли "оптимисты, шапкозакидатели, все-ни-по-чем, легко-решается-в-1С"

(54)>Я могу объяснить любое поведение 1с
- конечно-конечно.
Вот так: "1С так работает". И троектратное "да здравствует!" в конце.
Спасибо, все все поняли.

(54)>Но вот _тебе_
- ты с _собой_ сначала искренне побеседуй, а потом будешь выделять подчеркиванием остальных.

(56) намекаю. У меня дядя на бисерной фабрике не работает.
И на апельсиновой плантации тоже.

(37) Не должна так долго база реструктуризироваться. Какой регистр так долго обрабатывается?

(2) Для надежности.

(59) реструктуризация - самая длительная операция в ТИИ.
Если данных много - будет долго.

(61) Но не сутки же на базе всего в 100 гб !

(62) если без ошибок - то почему бы и нет.
Опять же - никто не в силах объяснить (даже если сильно-сильно надуть щеки и сделать умный вид, написав "я знаю"), что там происходит, и почему где-то быстро, а тут - долго.

(59) Долго документы и регистр Хозрасчетный. Может и не сутки, может часов 10.

(60) А в чем ненадежность в (2)?

(0) Могу предположить что простое добавление реквизита реализовано в корп версии платформы. Там можно "на лету" менять структуру данных.
А реструктуризация для нищих :)

(66) Ась?

(66) можно подробнее ?

(66) На лету нельзя. Можно в фоне, с кратковременным выгоном зверей в конце, на финальной стадии

(65) Библиотека XBase нечего не знает про транзакции. Такую реструктуризацию сделали для файлового варианта. А потом она (реструктуризация) в том же виде перекочевала на клиент-серверный вариант. Где она конечно же не нужна. Тут автор прав.

реструктуризацию (пересоздание таблиц с копированием) можно отключить с помощью ddl триггеров и подменой таблиц на пустые.

(69) Вот ведь блин. А тут написано http://v8.1c.ru/news/newsAbout.jsp?id=9320 фоновое обновление...
Я уж обрадовался.

(71) Подменять таблицы всей базы как-то шибко геморно

(73)

естественно в триггере.