Комментарии
Избранное
Подписка
Сортировка:
Древо
В 8 ке есть возможность в реквизитах указывать индексировать и индексировать с доп.упорядочиванием.
Насколько будет медленно или быстро в базе работать отбор по трем реквизитам, где один из них например переключается тумблером, а два других выбираются в форме?
Имеет ли смысл использовать родной индекс 1с в справочнике (владелец+родитель+реквизит) и организовать справочник или регистр сведений тоже будет хорошо работать (быстро переключать данные в таблице)?
Насколько будет медленно или быстро в базе работать отбор по трем реквизитам, где один из них например переключается тумблером, а два других выбираются в форме?
Имеет ли смысл использовать родной индекс 1с в справочнике (владелец+родитель+реквизит) и организовать справочник или регистр сведений тоже будет хорошо работать (быстро переключать данные в таблице)?
(2)
Вы это о чем? В форме в принципе индексов нет.. В статье речь идет о не нужных элементах
Насколько будет медленно или быстро в базе работать отбор по трем реквизитам, где один из них например переключается тумблером, а два других выбираются в форме?
Вы это о чем? В форме в принципе индексов нет.. В статье речь идет о не нужных элементах
То, что можно добавлять страницы (закладки), это все знают. Но тут нужно элементы формы размещать на каждую страницу. Как это избежать?
Для того, что бы использовать закладки совсем необязательно рисовать элементы формы на каждой странице.
Во вложении пример работы с закладками (без рисования элементов на каждой закладке)
Прикрепленные файлы:
УправлениеЗакладками.epf
(18)
Чтобы не тащить на сервер весь контекст формы, на которой может быть 100500 записей в таблицах, если на сервере нужно сделать что-то не зависимое от формы. Например, выполнить какой нибудь запрос и вернуть результат.
А нафига эти директивы компиляции придумали?
Чтобы не тащить на сервер весь контекст формы, на которой может быть 100500 записей в таблицах, если на сервере нужно сделать что-то не зависимое от формы. Например, выполнить какой нибудь запрос и вернуть результат.
То, что можно добавлять страницы (закладки), это все знают. Но тут нужно элементы формы размещать на каждую страницу. Как это избежать?
В (6) приведен пример того как этого избежать... Либо надо ставить вопрос по другому, либо....
По поводу скорости - в данном конкретном случае скорость вообще не важно ибо на глаз никто ее не заметит (0.005сек и 0,0005сек - никакой разницы визуально не будет)
Ничто не мешает нарисовать всё заранее в конфигураторе (если, конечно, у вас не лютый универсал), и просто рулить видимостью. Начиная с 8.3.8, кажется, изменение видимости не вызывает отправки формы на сервер и перечитывания, и потому работает быстро.
Что касается публикации - мне одному кажется, что это на уровне "как отсортировать список значений", по степени очевидности и примитивности?
Что касается публикации - мне одному кажется, что это на уровне "как отсортировать список значений", по степени очевидности и примитивности?
(7)Сколько элементов формы у Вас будет? Сколько надо прописать по управлению видимостью?
Здесь только два элемента. Строчек кода 100 и в большей части по управлению Табличной частью. Ни каких видимостей прописывать не надо. Оно само прорисовывается. Мечта программиста:)
Здесь только два элемента. Строчек кода 100 и в большей части по управлению Табличной частью. Ни каких видимостей прописывать не надо. Оно само прорисовывается. Мечта программиста:)
(8)Вырожденный пример.
Он подходит только для одного случая, когда различия только в отборе, накладываемом на таблицу.
Никакой заменой закладкам не является.
В большинстве случаев на разных закладках отображаются разные данные/требуется разное оформление и тд.
Он подходит только для одного случая, когда различия только в отборе, накладываемом на таблицу.
Никакой заменой закладкам не является.
В большинстве случаев на разных закладках отображаются разные данные/требуется разное оформление и тд.
(17)По сути вы "изобрели" отбор для таблицы.
Поэтому не совсем понятно, зачем так громко об этом заявлять.
О каком разгоне формы в принципе идет речь?
При наличии большого количества значений отборов или при длинном их наименовании - размещать их на форме в переключателях - выглядеть будет стремно. Да и смысла нет это делать.
Стандартный подход для этого - 2 таблицы, в первой таблице - значение ключ, во второй - записи по отбору текущей строки первой таблицы.
Поэтому не совсем понятно, зачем так громко об этом заявлять.
О каком разгоне формы в принципе идет речь?
При наличии большого количества значений отборов или при длинном их наименовании - размещать их на форме в переключателях - выглядеть будет стремно. Да и смысла нет это делать.
Стандартный подход для этого - 2 таблицы, в первой таблице - значение ключ, во второй - записи по отбору текущей строки первой таблицы.
(19)По сути я ответил на вопрос обсуждения, указанный в статье.Судя по всему, Вы ссылку не открывали. На изобретение велосипеда я не претендую. Это всего лишь интерфейсное решение того вопроса. Уверен, что оно самое быстрое. Можете пройтись с секундомером и сравнить решение в (6) и моё Благо замер производительности есть..
(23)
Дьявол в мелочах, Выигрываю на прорисовке формы, больше времени на завершении транзакции в проведении документа. А нафига лишняя миллисекунда на 3х терабайтной базе. Совсем не нужно. Лишнее наверное совсем:)
Давайте вернем коаксиал и все будет харашо:)
Кто не застал сего чуда это 10 мегабит на передачу инфы в очереди. 3G на тупом смартфоне быстрее
Скорость это еще не все =)
Дьявол в мелочах, Выигрываю на прорисовке формы, больше времени на завершении транзакции в проведении документа. А нафига лишняя миллисекунда на 3х терабайтной базе. Совсем не нужно. Лишнее наверное совсем:)
Давайте вернем коаксиал и все будет харашо:)
Кто не застал сего чуда это 10 мегабит на передачу инфы в очереди. 3G на тупом смартфоне быстрее
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|