Дня доброго.

"Выключи своё сознание, я не прошу понимания ,
Сколько мы раз убеждались - падали, но поднимались"

Знал эту тему раньше, но не было времени разобраться.
Читаем СП, видим:

ТаблицаЗначений (ValueTable)
Сортировать (Sort)
Синтаксис:

Сортировать(<Колонки>, <ОбъектСравнения>)
<ОбъектСравнения> (необязательный)

Тип: СравнениеЗначений.
Объект для сравнения значений. Независимо от того, задан объект сравнения или нет, элементы, чьи типы не совпадают, сравниваются по коду типа, а элементы простых типов сравниваются по значению. Дополнительно к этому:
если объект сравнения не задан, то элементы остальных типов сравниваются по строковому представлению;


Тоесть, для сортировки ссылочных типов будет извлечено его текстовое представление, ДАЖЕ когда этого не нужно (а это не нужно чуть менее чем полностью).

И действительно, для кода вида:

    Запрос=Новый Запрос;
    Запрос.Текст=
    "ВЫБРАТЬ ПЕРВЫЕ 100
    |    Номенклатура.Ссылка
    |ИЗ
    |    Справочник.Номенклатура КАК Номенклатура";
    ТЗ=Запрос.Выполнить().Выгрузить();
    ТЗ.Сортировать("Ссылка -");

на строчке кода ТЗ.Сортировать("Ссылка -"); 1С херачит 100 запросов на получение наименования.

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

Ну а я пойду переписывать свои коды.

(79) Есть. Конечно есть. Особенно если клиенты не живут в веб-браузерах.

(79) Прости. Не увидел заветные цифры 1986 сразу.

(79) Можно ссылку на оф. источник по пунктам 2 и 3?

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

p.s. Обрежем прозорливых - менеджеры ВТ во временное хранилище УЖЕ не помещаются, так как конфы поддерживают 8.3.

(82) Снимаю шляпу, тут действительно я загнался. У толстого клиента этих процессов не происходит, для него и сеанс, и соединение устанавливаются при старте и уничтожаются при завершении. Миграция данных производится либо при завершении работы процессов, либо при автоматической балансировке нагрузки.
Пруфы: http://its.1c.ru/db/v83doc#bookmark:cs:TI000000021

(62) Там оно выполнится и результат передастся на клиента
Туда не отсылаются не массивы, ни структуры ни ТЗ, если Вы рассмотрели код...
Тем самым обеспечивается минимальный трафик и загрузка сервера (странно, не правда ли?)

(85) Толстый клиент морально устарел, я вообще не понимаю, чего вы тут копья ломаете. Семерка и то перспективнее восьмерочного толстого клиента)

(87) сфигали он устарел? Разверни тему, будь ласка...

(88) Новые типовые делаются на УФ, редкие исключения только подтвердят правило. Через пару лет на толстом клиенте останутся только те, кто подсел на самописку. В точности как семерочники.

(89) Если новые типовые на УФ (с) будут того же уровня, что и БП и ЗУП 3, то лучше не надо. Я лучше на old cmelly crock of shit посижу.

А то где это видано, чтобы бухгалтерия обновлялась (ТИПОВАЯ!) в 4 раза дольше, чем УПП....

(91) Скажите спасибо БСП. Тонкий клиент и УФ тут ни при чем.

(92) Когда в конфе, не использующей БСП, новая (!) форма обработки открывается 3 минуты, кому сказать спасибо?

(93) Не могу себе такого представить. Моя самописка на УФ (приложение к БП3 для расчета плановой себестоимости) без использования БСП запускается и работает очень шустро.

(94) не запускается. А открывается в конфигураторе для редактирования.

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

(96) А с обычными формами не лажанулись? Конфигурация на клиенте грузится 5 минут и съедает 300 мегов памяти. Так делать нельзя. Считаю, что обычные формы - потерянное напрасно время.

(97) Закэшированная не грузится. Что такое 300 мегов для современных даже не компьютеров, а смартфонов?

(79) "Есть еще вопросы по масштабируемости?" конечно есть. Расшифровку цифр приведите пожалуйста. Что за конфигурация серверного оборудования (включая СХД), какова конфигурация рабочих машин, и какой код будет выполняться быстрее. Вдруг Дмитрий прав, в сообщении (81).

(86) Прочитайте пожалуйста еще раз мой вопрос. Он не касался вашего кода, а касался ваших рекомендаций:
- "куярить все на сервере"
- "чему тебя в школе учили ..., ковыряться в ТЗ на клиенте?"

Каким образом Вы обеспечиваете масштабируемость системы, если любая обработка информации по Вашему мнению должна происходить исключительно на сервере?
А применимо к Вашему коду, скажите какое звено в трех уровневой архитектуре загружается в вашем примере и что с ним будет, если прочие расчетные задачи будут решаться аналогичным образом?

100

(97) Откуда цифры 5 минут и 300 метров? У меня буха корп 2.0 с большим вагоном новых объектов грузится меньше минуты и съедает 100 метров примерно.

(101) Ну, всё от мощности компьютера зависит. У пользователей компы заменить все - намного дороже, чем проапгрейдить сервер. Поэтому восьмерочные тонкие клиенты - следующий шаг после семерки.. а толстые клиенты - "музыка толстых")

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

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

(103) (104) про сервер чего разговор?

(105) Про сервер 1с, разумеется.. а вы про что?

(106) а я не про что, я просто развлекаюсь, видя как без конкретных нюансов системы строят идеальное решение :)

(0) Полезная инфа, спасибо. Не задумывался, что все может быть настолько плохо, хотя где-то про второй параметр и помнил.
(107) Какие экзотические ньюансы учетной системы могут в современных условиях отдать предпочтение переносу нагрузки с сервера на клиенты, а не наоборот?

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

(99) Это ты мне предлагаешь ужом да змейкой пролезть под Hyper-V и вытащить реальную физическую инфрастуктуру? Или может мне нужно обегать все клиентские компы? Так этих самых клиентских компов наберется под сотню и разбросаны они по европейской части страны достаточно хаотично. И закупались в очень разные годы, значительная часть парка видела еще клюшки.

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

Хотя я еще помню ныне похеренную методику распределенных вычислений, которая публиковалась в ЖКК на заре 8.1. Тогда предлагалось большие отчеты-расчеты пилить на куски и раздавать машинам в сети для совместного расчета. Вот только что-то не пошло, потерли тему со всех учебников.

(110) "А теперь главный вопрос - зачем вообще на клиенте появилась большая таблица?"

Пфффф. Легко.
Редактирование 6 формы декларации по алкоголю.
Дабы не вылетало по памяти - редактируем кусками по 10000 строк, юзер выбирает блок, только так.

p.s. И даже в этом случае, узким местом остается Сервер 1С, ибо УФ и идет XDTO сериализация. Это конечно не относится к обработке данных, но как бы говорит нам, что серверу есть дохера чем заняться, особенно под Тонкими клиентами. Хорошо хоть редактируют эту 6 форму редко и ограниченное число пользователей.

(111) У вас в учете бардак, что приходится редактировать? Ну так бардак и надо устранять - чтобы не редактировать.

(110) "Тогда предлагалось большие отчеты-расчеты пилить на куски и раздавать машинам в сети для совместного расчета."

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

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

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

(115) Ну почему? Вкупе с книгой учета доходов и расходов на 10-20 тыс. страниц (причем этот отчет реально печатали раньше) это весьма денежные отчеты. Потому что Excel не переваривает такой объем.

P.S. Если что - книга учета доходов и расходов содержала более 1 млн. строк. По сравнению с этим 100500 строк - мелко. Вот такой вот ИП ;)

(112) Учет у клиентов, с нас - взятки - гладки и возможность редактирования.

Ребят, вы не считайте себя умнее других, не катит это.

(114) Плохо. Простейший пример - интерактивная загрузка из файла.

(0) На правах вброса - а какой прикладной смысл вкладывается в эту операцию (сортировке таблицы значений по ссылочному полю)?

(117) Ловко, конечно, но ты дал мотыгу юзеру - и он вкалывает. А мог бы продать мотокультиватор - сделать автоматический подгон под заданные параметры и срубить намного больше ;)

+(120) И, кстати, что мешало сделать РС со структурой формы 6 и дать юзеру форму списка для редактирования?

(119) Уже писал. Программная группировка.
(120) Что за автоматический подгон?
(121) Думал и над этим. Необходимость наличия как минимум 3 измерений (Пользователь, РегОтчет, НомерСтроки), невозможность редактирования записи в динамическом списке.

(121) Но, каюсь, не тестировал быстродействие с РС. Блоки по 10000 строк нормально отрабатывают на сервере sql-1С 2006 года закупки.

(25)  а Индекс по номенклатуре чего не добавил? ищешь ведь по ней потом в цикле...

(122) Был невнимателен, да и сейчас не особо врубился.
Т.е. сортировка нужна только для того, чтобы разбить таблицу на порции по 1000 строк?

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

(122) Когда пользователям надоело выводить учет и редактировать отчет из 500 тыс. строк, они сказали: "У нас есть уже готовая укрупненная отчетность, мы можем вбить итоги - надо подогнать детальные записи под эти итоги". Сказано - сделано. Юзеры вводили к какому ответу надо подогнать отчет - а обработка сама разбрасывала корректировки как надо. За этот подгон я срубил весьма прилично бабла, потому что пользователи ленивые и постарались убедить начальство в том, что эта доработка стоит запрошенных денег.

P.S. Правда я запросил много чтобы начальство зарубило эту инициативу. Но пришлось делать :)

(124) Маловато данных для индекса "на 1 раз". Не в том смысле, что поиск 1 раз, а в том, что индекс жить будет недолго.

(125) Вы откуда такие ограниченные. Вот есть у нас тз. Все. Один раз я ее суко получил, потом кручу на клиенте, как хочу. Отлично подходит под концепцию распределения по клиентам.

Да, специально для (упоротых, зачеркнуто) упертых, получаю я ее из ДокументОбъект.Товары.

(126) Херней не занимаемся. Если интересно, посмотри как декларации в ФСРАР сдаются.

(128) Это ответ на 2 вопрос. Ответ для чего нужна сортировка и что такое "программная группировка" в (25) (28)

(130) Посмотрел код. Господи, как хорошо что таблицу значений на клиенте для УФ так и не реализовали.

(131) Почему ты в этом так уверен :-)

(131) Что не так в коде?

(132) В чем уверен? Что не реализовали? Нету ее полноценной на клиенте.

(133) Потребление памяти и быстродействие. Чего стоит только выгрузка всех алкогольных номенклатур в таблицу значений и многократный (в цикле) перебор этой таблицы при вызове ТаблицаАлкогольныхНоменклатур.Найти().

(134) "Потребление памяти и быстродействие. Чего стоит только выгрузка всех алкогольных номенклатур в таблицу значений и многократный (в цикле) перебор этой таблицы при вызове ТаблицаАлкогольныхНоменклатур.Найти()."

У вас мозги промыты мантрой "делайте все на сервере SQL".

Он делает точно такой же перебор , ну, может чуть быстрее из за MergeJoin

(134) "В чем уверен? Что не реализовали? Нету ее полноценной на клиенте. "

**зевает.

Позволь показать тебе немного магии...
http://s019.radikal.ru/i618/1411/85/fcdc5b05f4ed.png

(136) модальность зло

(137) Это пример того, что реализована даже графическая часть.

(135) Не сделает СУБД многократный перебор в цикле(!!!). При нормально написанном запросе, с индексами для временной таблицы и т.д.
И я не говорил "делайте все на SQL" :) Но в данном случае включать режим д'Артаньяна не стоит.

(136) **зевает-в-квадрате. Уверенны, что не сломается Ваша магия внезапно спустя полгода?
Ну и про поддержку веб-клиентов и всяких линупсов для вашей ВК я конечно не спрашиваю, ответ и так понятен.

(135) Утомил ты своим алкоголем...
Так же как и пейсатели типовых "с понтами но для ларьков"...
Оказывается есть большие предприятия! И там не удается провести книги продаж, так как не влазит в документ более 100 000 строк.
Все твои алкоголи при правильной структуре базы и подходу к обработке данных просвистят мама не горюй.

(118) Есть ответ и на это. Загрузка из файла в 6 тыс. строк екселя длится секунд 5-6. Не наблюдались ни падение производительности, ни угроза для масштабируемости.

Забавный холиварчик. Я за мощные сервера и код на нем. Код на клиенте можно взломать дизасемблером и внедрить в него вирус.
Редактировать много записей на клиенте стал бы через регистр сведений. Меньше кода - меньше ошибок. Пусть платформа думает об оптимизации, она же умная.

(135) Во-первых, я надеюсь,  поле в таблице алкогольных затрат хотя бы проиндексировано. И в этом случае это не будет перебор.
Во-вторых, MERGE JOIN быстрее nested loops не "чуть", а "охренительно".
В-третьих, hash match тоже сильно быстрее.
В-четвертых, вы не учитываете расход памяти на выполнение всех этих соединений на клиенте.

У вас мозги промыты мантрой "ничего не делать на SQL".

Приведённый код - это программирование в стиле 7.7.

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

ИМХО, спор ни о чем.
Пытаться выполнять обработку на клиенте исключительно из соображений разгрузить сервер так же глупо, как загонять клиентскую ТЗ на сервер только для того, чтобы выполнить элементарные манипуляции средствами SQL.

(139) Охеренно.

СУБД делает многократный перебор в цикле хотя бы потому, что законы природы для нее никто не отменял.

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

Насчет магии - речь шла о том, что ТЗ на ТОНКОМ все таки реализована, просто недоступна смертным.

(140) Посетите роскошные леса Белоруссии в районе Бобруйска.

(142) В следующий раз не поленюсь, попробую реализовать через РС, соблазнили вы меня :-)

(143) Проиндексировал, потому что поиск по этому полю будет многократен.

(143) MergeJoin быстрее nested loops только когда нет подходящего индекса для соединения. Как только появится индекс в большей таблице - nestedloops однозначно быстрее.

(143) ЧТо насчет расхода памяти при поиске? Есть какие-то сенсации?

nestedloops быстрее MergeJoin ? Ты точно уверен?
Как однопроходное соединение может быть медленнее кучи поисков?

(152) Mergejoin означает tablescan 2 таблиц.
nestedloops означает tablescan меньшей таблицы и indexseek по большей.

(153) Хотя подожди. Я ступил. indexseek в цикле, пусть и быстром. По факту, обойдутся все узлы индекса, это будет аналогично indexscan-у.

(153) Ты это по замерам судишь, или твой мозг опять родил новую теорию?

(152) MergeJoin хорош для полного соединения или поиск на больше или меньше. Для соединения больше используется Алгоритм соединения хэшированием.

(101) Прям щас:
рабочая УПП на жирном клиенте + БИТ.ФИНАНС, 427 метров в памяти (ни одна форма еще не открыта). Загрузка около минуты.
Она же в тонком клиенте: загрузка 15 секунд, 29 мб в памяти.

Ну расскажите фанаты жирных клиентов что там не так, и какие УФ плохие.

(155) Ты продолжай прыгать, Анатолий.

http://support.microsoft.com/kb/197297
Если индекс существует ключа соединения, данные не нужно отсортировать и Поэтому соединение слиянием будет лучшим выбором.

(156) и как раз на больше меньше мердж не работает
>> |Needs at least 1 equality

(160) Давай ты почитаешь еще раз.
http://msdn.microsoft.com/ru-ru/library/ms190967(v=sql.105).aspx

(160) Хотя лучше вот здесь
http://www.sql.ru/articles/mssql/2007/051102mergejoin.shtml

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

Ну, в принципе "Needs at least 1 equality" так и переводится.

(160) Прошу прощения. На больше меньше там поиск по индексу.
Здесь Хэш в пролете, а слияние здесь не в тему. Он хорош для полного соединения.

Кстати а алкоголики всю отчетность в бумажном виде сдают?
http://vz.ru/news/2014/11/5/713937.html

(165) С 2014 только електронка.

(127)
> Маловато данных для индекса "на 1 раз". Не в том смысле, что поиск 1 раз, а в том, что индекс жить будет недолго

фраза не понятна. в смысле, что за аргумент - "жить будет недолго"?
понятны вот такие аргументы:
1. ищу по этому полю только 1 раз, поэтому индексирование будет более дорогой операцией чем однократный поиск.
2. у меня всегда в этой таблице 1(2, 3, 4) строки...
- это понятные аргументы, хотя п.2 может быть аргументом в строго ограниченных случаях. потому что, в общем случае никогда не знаешь, может быть завтра там будет уже тоже самое только с приставкой тысяча.

а вот что такое "жить будет недолго" непонятно. есть определение данной совокупности слов?

p.s. во временных таблицах по такому же принципу Индекс то ставишь, то не ставишь?

или всё-таки по какому-то другому (например, то что это поле потом участвует в соединении)?

p.p.s. эксперта говоришь не сдал? ;)

Дятел, он и с УПП дятел, даже если сделает умный вид...

(167) Согласно статистике - в ТЧ документа строк мало, поэтому, как правило - поиск производиться несколько раз (3-5) в Таблице из 50 строк. Поэтому индекс не нужен.

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

Именно это я имел ввиду под "жить будет недолго".

Вы забавные. Прямо забавно наблюдать поиски ответа на вопрос: "Что лучше, одеяло (nested loops), полотенце (merge join) или флаг (hash match)?"

(172) и таки есть ответ на этот вопрос в (159)

Смешно... вот она, АВТОМАТИЗАЦИЯ больших пр-тий "а ля 1С".
Люди, перебирающие построчно ТЗ, тыркают друг другу ссылки на мсдн, скл и технет...

(174) перебирает тут один только )))

(173) Ага, ага. А если индекс не уникальный?

(175) Он явно религиозный фанатик

(176) Это ты с MS споришь???

(178) А что где-то в обсуждении участвует MS? Я пока пытаюсь понять, ты сам хоть что-то понимаешь, или тупо ссылки копируешь...