0. vandalsvq 1146 13.06.18 23:50 Сейчас в теме

Что делать, если строк в документе больше 99'999?

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

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. Merc 14.06.18 09:58 Сейчас в теме
Так и скажи, что не любишь динамические списки.
Dmitri93; +1 Ответить
2. vandalsvq 1146 14.06.18 10:05 Сейчас в теме
(1) скажи на милость, чем мне динамический список поможет? Отображать данные? Ну ок. Только в этом и все, хотя для отображения тоже не выйдет, в расшифровке выводится дерево: смета - позиция/ресурс
6. Merc 14.06.18 10:50 Сейчас в теме
(2) Динамический список умеет в дерево

99к + строк в данных формы это абсурд, как ссылка на вх или что-то ещё:

1. Отобразить их невозможно, видимая часть списка это не так много строк
2. Если есть задача отражать изменения при записи, храни изменения в данных документа
3. Изменений больше 99к? Если да - взгляни на закрытие месяца, там тоже много изменений и ни кто не складывает их в ТЧ.

ПС: Твоя проблема и её решение это одна большая ошибка.
8. vandalsvq 1146 14.06.18 10:59 Сейчас в теме
(6) 1. Отображать всю таблицу никто не собирался. Отображается только часть, имеющая отношение к текущей строке материала, тем более в момент «запроса» пользователя.
2. Изменять их напрямую пользователь не будет, он управляет материалами, а программа связанными с ними строками «истории» сбора данных.
3. Вот поэтому в тч хранить и не стали. Это ни к чему.

Опять повторюсь, я кажется дал с самого начала достаточно информации для создания альтернативной структуры хранения.
12. Merc 14.06.18 11:53 Сейчас в теме
(8)

Предложение 1:

1. Пользователь, что-то делает с материалами
2. Это что-то сохраняется в документ
3. При записи/проведении рассчитываются изменения и куда-то складываются

Предложение 2:

Из регистра сведений удаляется документ как измерение и устанавливается периодичность по регистратору

1. Создается и записывается документ
2. Все действия пользователя сразу пишутся в РС
3. Пока документ не проведен, активность записей - Ложь
17. vandalsvq 1146 14.06.18 12:25 Сейчас в теме
(12) вот это другое дело ;), давай обсудим.

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

Предложение 2 в принципе предложение рабочее. Есть один нюанс, пока не нажата кнопка "Записать" обычно пользователю считают что все изменения - это "вилами на воде писано". При обрыве соединения сохранятся изменения регистра, но данные объекта документа не изменяться. Или зависнут "неактивные" позиции и их придется как то потом подчищать.
20. Merc 14.06.18 13:15 Сейчас в теме
(17)
Педложение 1 по сути есть продолжение описанного в статье. После того, как данные были собраны, они могут быть изменены, вот эти изменения будут проанализированы и в расшифровку точечно внесены изменения.


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

Почему и про нюансы:

1. Сам факт существования объекта иб при создании можно скрыть, для этого достаточно сделать отбор по какому-то его реквизиту в списке
2. При обрыве соединения пользователь не потеряет данных, можно будет дать возможность продолжить творчество с того места где он остановился.
3. Активность как свойство записи входит в индекс и по умолчанию не попадает в срезы, очистка данных может быть не оперативной.

Самое главное:
1. Мы не сталкиваемся с ограничениями при масштабировании в большую сторону.
22. vandalsvq 1146 14.06.18 14:10 Сейчас в теме
(20) я возможно не во все въехал сейчас, попробую проанализировать позже. Есть хорошая идея о том что "творчество можно продолжить". Это интересно может показаться, исходя из того с каким отделом мы имеем дело сейчас.
25. Merc 14.06.18 14:39 Сейчас в теме
(22)

Вообще периодичность по регистратору и активность можно не использовать.

Документ и признак активности могут быть самостоятельными измерением, основная идея в следующем:

1. На форме пользователь видит данные полученные объектами с поддержкой чтения по курсору (РегистрСведенийСписок, ДинамическийСписок)
2. Изменения сразу фиксируются в базу данных
3. Окончательное принятие к учету происходит с использованием доп. признака активности.
3. A_Max 18 14.06.18 10:16 Сейчас в теме
Рассматривали вот такой вариант?
При создании документа генерировать новую ссылку документа и везде использовать её (при записи применять её). Соответсвенно вместо таблицы значений использовать динамический список с отбором по ссылке (реальной или сгенерированной при создании нового).

PS: Увидел, что я не первый уже после отправки комметария :о)
4. vandalsvq 1146 14.06.18 10:36 Сейчас в теме
(3) тогда бы понадобилось сразу после сбора данных записывать их в базу. А этого делать не хотелось. Пользователь не факт, что документ запишет, да и время на запись тоже необходимо. А после отказа от записи документа удалять данные. В общем это вызывает доп. расходы, а не хотелось этого.
Поэтому при сборе получаем таблицу значений, закидываем во временное хранилище, работаем с ней. А если открыт существующий документ, то считываем либо все сразу, либо по частям и тоже в ТЗ и во временное хранилище.
Кстати, писал выше, поскольку отображение в виде дерева, динамический список не удастся использовать. Хотя для других случаев, берем наш регистр сведений и выводим.
13. A_Max 18 14.06.18 11:57 Сейчас в теме
(4) Именно поэтому и спросил рассматривали такой вариант или нет. Да, именно в вашем случае, когда может быть загружен большой объём и после этого велика вероятность отказа от записи, более логично времено хранить на клиенте. Но тогда мы увеличиваем требования на клиентскую часть (объём памяти и частично процессор на обработку) вместо того чтобы этим занимался сервер (вообще файл передать на сервер для загрузки). В случае с динамическим списком как минимум отпадает необходимость отработки частичного чтения. Возможность "отката" тоже реализовать на вскидку в голове пара способов крутится.

У каждого решения есть своя сфера применимости с плюсами и минусами.


ПС: При очистке регистра не нужно его читать. Можно сразу записывать набор после установки отбора.

ПС2: Не надо так резко воспринимать комметарии, этим только вызываете общий негатив.
15. vandalsvq 1146 14.06.18 12:15 Сейчас в теме
(13) маленькая поправка, на клиент весь набор собранных данных (все эти много строк) не передаются, они во временном хранилище остаются. У клиента есть адрес хранилища, и при необходимости через вызов сервера, он может получить ровно ту часть строк, которые в текущий момент необходимо отобразить.
В общем получается такая схема:
- если нажата кнопка "Заполнить", то считанные данные помещаются во временное хранилище. Клиент получает ответ что все собрано и таблицу только уникальных позиций материалов, а вся расшифровка остается на сервере. На клиенте никоим образом отражения она не находит.
- после записи документа,при повторном открытии, мы не сразу заполняем все данные расшифровки. Возможно пользователю она вообще не понадобится в процессе работы. Когда пользователь запрашивает необходимость расшифровки, именно эта часть считывается из регистра и дополняется в таблицу хранилища. Таким образом, мы его наполняем постепенно.

Во всех случаях на клиенте остается только адрес хранилища и видимая часть уникального набора материалов.

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

Пс2. видимо спал вчера мало, прошу прощения у всех
5. bulpi 173 14.06.18 10:41 Сейчас в теме
Если у вас строк в ТЧ более 999999 , это значит, что вы неправильно спроектировали базу. Это аксиома.
le0nid; cegorach; Merc; Dream_kz; +4 2 Ответить
7. vandalsvq 1146 14.06.18 10:51 Сейчас в теме
(5) аксиома говоришь? А теорема то кем была выдвинута? И критикуя - предлагай. Я готов обсуждать если будет что 🤗. В самом начале, постарался объяснить почему так получилось. Думаю достаточно, чтобы сделать иное предложение.
TreeDogNight; +1 Ответить
9. artgen 14.06.18 11:30 Сейчас в теме
Разбить на несколько документов.
10. acanta 74 14.06.18 11:50 Сейчас в теме
Какова зависимость времени записи документа от количества строк в 8ке?
11. Vladimir Litvinenko 14.06.18 11:52 Сейчас в теме
Идея хорошая. Возможно будут полезны замечания.

1) Обернув код записи набора записей в Попытку-Исключение в уже открытой транзакции записи документа получили возможность возникновения невосстановимой ошибки во "вложенной" транзакции. Комбинация адекватного сообщения пользователю, выдаваемого методом ОбщегоНазначенияКлиентСервер.СообщитьПользователю и пугающего диалога с "В данной транзакции уже происходили ошибки" - это не лучшее решение. Нужно выбрасывать возникшее исключение выше через ВызватьИсключение а не просто сообщать пользователю. Тогда этот метод записи данных можно использовать и в серверных алгоритмах вне интерактивного взаимодействия с пользователем.

2) Перед заполнением набора записей в методе ЗаписатьДанныеВременногоХранилища блокировка данных не нужна. Вы же не выполняете предварительного чтения чтобы новые данные писались на основе старых. И вы же не ставите такую блокировку в методе ОчиститьРегистрСведенийХранениеДанныхДокумента, где точно такой же код за исключением того, что цикл заполнения набора записей заменен на метод чтения из БД.

3) Зачем в методе ОчиститьРегистрСведенийХранениеДанныхДокумента вообще чтение из БД?

НаборЗаписей.Прочитать();
НаборЗаписей.Очистить();
НаборЗаписей.Записать(Истина);

Вроде бы как в регистре большое количество данных. Зачем их читать на сервер 1С чтобы потом сразу очистить эти данные и снова записать? Здесь ничего кроме установки неявной разделяемой управляемой блокировки не произойдет. И думаю что метод чтения из БД кучи данных вызывается вовсе не с целью установить неявную блокировку. Таким образом этот вызов является ошибкой.

4) Регистр перезаписывается целиком для документа. Если нам нужно добавить данные к уже существующим или удалить только часть данных, то алгоритм придется менять, и в методе ЗаписатьДанныеВременногоХранилища придется все-таки добавлять предварительное чтение всего объема данных по документу из регистра. Чтобы затем поменять только часть записей. Это очень не оптимально, учитывая исходные условия задачи : большой объем данных по документу.

Если обеспечить идентификацию строк в документе в свернутой таблицы материалов (например добавить автозаполняемый реквизит с типом УникальныйИдентификатор или инкрементальный числовой идентификатор), то можно было бы сделать вторым измерением регистра идентификатор строки. В этом случае получили бы больше возможностей по независимому изменению расшифровки каждой строки.
acanta; vandalsvq; A_Max; +3 Ответить
14. vandalsvq 1146 14.06.18 12:05 Сейчас в теме
(11) спасибо за замечания все по делу. Действительно полезно.

1. Да, вы правы. Спасибо за подсказку, изменения будут внесены.
2. Использовать блокировку стало какой-то привычкой, причем видимо мозг уже отключается о причинах, зачем это делается. Так же согласен.
3. Чтение тоже ни к чему, согласен также.
4. Вот тут маленькая поправка. Выложил не всю информацию, сознательно ее упростив. Ваше замечание верно, и оно реализовано.
Регистр имеет структуру: Документ / Ключ строки / Смета / Ключ позиции сметы
Т.е. при необходимости можно перезаписать все данные, а можно по отдельным ключам, которые были изменены. Поскольку механизм взаимодействия пользователей сейчас в работе, процедура записи не была пока изменена. Но в будущем, когда из формы будут приходить данные об изменениях только отдельных групп строк, тогда будет реализована и запись части набора, без затрагивания остальных.
19. Vladimir Litvinenko 14.06.18 13:03 Сейчас в теме
(14)
Если реализован регистр с измерениями Документ / Ключ строки / Смета / Ключ позиции сметы и данные действительно перезаписываются не целиком по измерению Документ, а по сочетанию измерений, то при запись данных в регистр сведений в методе ЗаписатьДанныеВременногоХранилища скорее всего идет внутри цикла, перебирающего комбинации измерений.

В таком случае управляемая блокировка до начала записи действительно нужна. И тогда пункт 2 из замечаний надо вычеркнуть. Иначе параллельная транзакция читая данные в целом по документу может получить несогласованный набор данных, состоящий из части "новых" расшифровок строк и части "старых" расшифровок. Вообще тут думать надо исходя из того, возможно ли такое чтение в других сеансах.
23. vandalsvq 1146 14.06.18 14:12 Сейчас в теме
(19) чтение возможно, но критичного в несогласованности ничего не будет, хотя бы потому что пока ведомость не подписана как часть договора (соглашения) она доступна к редактированию, а после подписания она недоступна и только тогда она нужна уже как источник данных.
Все таки я частенько блокировки накидываю по привычке. Долго работал над собой чтобы писать блокировки, теперь надо работать над собой чтобы не писать блокировки )))))))
16. Infector 155 14.06.18 12:17 Сейчас в теме
В общем-то пользуюсь подобным механизмом чтобы не добавлять нестандартные табличные части в стандартные объекты УПП. При создании на сервере формы существующего объекта читаем набор записей в реквизит формы, после записи формы - пишем содержимое этого реквизита в набор записей. Не забываем принудительно распихать ссылку объекта в соответствующий реквизит.
18. vandalsvq 1146 14.06.18 12:26 Сейчас в теме
(16) я не хотел хранить таблицу в реквизите формы, поскольку при любом контекстном вызове сервера мы получим эти данные в пакет.
21. Infector 155 14.06.18 13:20 Сейчас в теме
(18) в общем-то на уровне интерфейса решений может быть уйма. Динамический список с отборами тоже неплохое решение. Есть еще вариант с записью регистра с подчинением документу, при этом на форму можно просто кинуть таблицу из движений. Главное тут то, что решения с регистрами сведений неплохо работают.
24. vandalsvq 1146 14.06.18 14:16 Сейчас в теме
(21) мне лично показалось интересным заменить реквизит формы с большой таблицей, хранением этой самой таблице на сервере. Я еще отдельно проведу тесты на потери времени на получение и помещение, особенно когда речь пойдет о редактировании ее. Там получится ведь что сначала ты ее извлекаешь, меняешь, потом полностью обратно суешь. Не зная конвертирует ли 1С ТЗ в какой то внутренний формат или нет, сложно сказать накладные потери сходу.
А использование регистра сведений как замены таб. части, тут лежало на поверхности, да и как то раньше в памяти помню как-то на мисте даже поднимался 100 лет назад подобный вопрос.
26. mszsuz 232 17.06.18 13:38 Сейчас в теме
Ещё вариант - сделать ДВА регистра - один для хранения данных документа, второй - временный - вывести на форму для редактирования.
Заполняем временный при открытии документа. После закрытия документа, если были изменения переносим данные из временного в основной. И чистим временный.
27. A_Max 18 18.06.18 10:12 Сейчас в теме
(26) Излишняя сущность, т.к. можно использовать "Активность" записи у одного регистра или ещё какой-то статус добавить. Плюс от отдельного регистра может оказаться только в отсутсвии индексов для ускорения вставки.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Специалист 1 категории (Методист-аналитик 1С)
Фрязино
зарплата от 100 000 руб.
Полный день

Главный архитектор 1С
Москва
зарплата от 200 000 руб. до 300 000 руб.
Полный день

Программист 1С
Новороссийск
зарплата от 70 000 руб.
Полный день

Ведущий программист 1С
Санкт-Петербург
зарплата от 130 000 руб.
Полный день

Специалист 1 категории (Программист 1С ФЗД)
Фрязино
зарплата от 110 000 руб.
Полный день