Дня доброго.

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

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

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

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

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


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

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

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

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

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

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

Странно, что 1С запилила такой алгоритм сортировки по умолчанию.

Данное справедливо для ТабличныхЧастей и СтрокДереваЗначений.

выгузками в ТЗ и обработкой результата там занимается наверное половина 1с программистов

по моему, за выгрузки в ТЗ иппут даже на сдаче экзамена по 1с плаформе. лично я давно уже все запросами делаю.

(3) Для тебя Дмитрий Сергеевич. Попробуй еще раз.

(5) Не все такие альтернативно одаренные, многие работают с православными ТЗ.

(0) а зачем сортировать ссылки?

(9) Программная группировка, например.

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

(11) Я последователь минимальной загрузки сервера 1С, и, особенно сервера SQL, пусть ТолстыйКлиент работает, серверам и без вас есть чем заняться.

(0) если у разных ссылок одинаковое наименование, ТЗ.Сортировать("Ссылка -") может их перемешать между собой? как это произойдет в семерке? или одинаковые ссылки будут идти подряд?

* может их перемешать между собой? (как это произойдет в семерке)

(13) Не проверял, в СП не сказано.

(14) Думаю, мешать не будет, сохраниться исходный порядок, тоесть, отработает не так, как было рассчитано.

(0) Обычно если сортирую ТЗ, то сортирую по базовым типам.

Та пох ;)

Я и с первым то ... Не очень.

(10) по одной колонке? зачем?

Если поменьше нагружать сервер, то лучше делать по максимуму в запросах и тестировать все варианты через отладчик на время исполнения.

(5) ТО есть загрузка из запроса в ТЧ тоже не приветствуется?

(16) в 7-ке если дать такую таблицу

ссылка3 (представление "тест2")
ссылка1 (представление "тест1")
ссылка2 (представление "тест1")
ссылка1 (представление "тест1")

то сортировка даст

ссылка1 (представление "тест1")
ссылка2 (представление "тест1")
ссылка1 (представление "тест1")
ссылка3 (представление "тест2")

я думал, что 8-ка избавлена от этого, теперь буду пользоваться сортировкой аккуратнее)))

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

order by добавлять? или что надумал?

(20) как пример:

    ТаблицаЗаписей=НаборЗаписей.Выгрузить();
    ТаблицаАлкогольныхНоменклатур=СтруктураОбъектовАлкогольнойПодсистемыПроведения.ТаблицаАлкогольныхНоменклатур;
    ТаблицаЗаписей.Сортировать("Продукция", Новый СравнениеЗначений);
    ТекущаяПродукция=Неопределено;
    ЭтоАлкогольнаяПродукция=Истина;
    ТекстСообщения="";
    ЕстьОшибка=Ложь;
    Для Каждого СтрокаТаблицыЗаписей Из ТаблицаЗаписей Цикл
        Если ТекущаяПродукция<>СтрокаТаблицыЗаписей.Продукция Тогда
            ТекстОПродукцииСформирован=Ложь;
            ТекущаяПродукция=СтрокаТаблицыЗаписей.Продукция;
            ЭтоАлкогольнаяПродукция=ТаблицаАлкогольныхНоменклатур.Найти(ТекущаяПродукция,"Номенклатура")<>Неопределено;
        КонецЕсли;
        Если ЭтоАлкогольнаяПродукция Тогда
            Продолжить;
        КонецЕсли;
        ТекущаяЗатрата=СтрокаТаблицыЗаписей.Затрата;
        ЭтоАлкогольнаяЗатрата=ТаблицаАлкогольныхНоменклатур.Найти(ТекущаяЗатрата,"Номенклатура")<>Неопределено;
        Если Не ЭтоАлкогольнаяЗатрата Тогда
            Продолжить;
        КонецЕсли;
        
        Если Не ТекстОПродукцииСформирован Тогда
            ТекстСообщения=ТекстСообщения+Символы.ПС+Символы.Таб+"Для неалкогольной продукции "+ Строка(ТекущаяПродукция)+ " используются следующие алкогольные затраты:";
        КонецЕсли;
        ЕстьОшибка=Истина;
        ТекстСообщения=ТекстСообщения+Символы.ПС+Символы.Таб+Строка(ТекущаяЗатрата);
    КонецЦикла;

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

ИХМО - программную сортировку вообще нужно заменять на сортировку скулем...

(25) Сортировка мне нужна, чтобы сгрупировать обработку ТЗ по колонке "Продукция"

        Если ТекущаяПродукция<>СтрокаТаблицыЗаписей.Продукция Тогда
            ТекстОПродукцииСформирован=Ложь;
            ТекущаяПродукция=СтрокаТаблицыЗаписей.Продукция;
            ЭтоАлкогольнаяПродукция=ТаблицаАлкогольныхНоменклатур.Найти(ТекущаяПродукция,"Номенклатура")<>Неопределено;
        КонецЕсли;

(25) Вот так надо, куярить все на сервере, чему тебя в школе учили пилять, ковыряться в ТЗ на клиенте? Зачем тогда восьмерки придумали?

//назначаем товары по справочнику соответсвий, признак назначен по соответствию = 1
    ТекстЗапроса = "
    |UPDATE OM_ContPrices
    |SET GoodsId    = $НП.Номенклатура
    |, Compl        = 1
    |FROM OM_ContPrices
    |INNER JOIN $Справочник.УЗ_НоменклатураПоставщиков AS НП (NOLOCK) ON OM_ContPrices.Price = $НП.РОЦ AND OM_ContPrices.ExpDate = $НП.СрокГодности AND OM_ContPrices.IdGoods = НП.CODE
    |INNER JOIN OM_Prices (NOLOCK) ON OM_ContPrices.IdPrice = OM_Prices.Id AND :Пользователь = OM_Prices.UserId
    |WHERE GoodsId = '         '
    |";
    
    RecordSet.УстановитьТекстовыйПараметр("Пользователь", глПользователь);
    
    RecordSet.ВыполнитьИнструкцию(ТекстЗапроса);
    
    //назначаем товары по штрихкодам, признак назначен по соответствию = 0
    ТекстЗапроса = "
    |UPDATE OM_ContPrices
    |SET GoodsId    = Ном.ID
    |, Compl        = 0
    |FROM OM_ContPrices
    |INNER JOIN $Справочник.Номенклатура AS Ном (NOLOCK) ON OM_ContPrices.Barcode = $Ном.ШтрихКод
    |INNER JOIN OM_Prices (NOLOCK) ON OM_ContPrices.IdPrice = OM_Prices.Id AND :Пользователь = OM_Prices.UserId
    |WHERE GoodsId                = '         '
    |AND OM_ContPrices.Barcode    <> '             '
    |";
    
    RecordSet.УстановитьТекстовыйПараметр("Пользователь", глПользователь);
    
    RecordSet.ВыполнитьИнструкцию(ТекстЗапроса);

.....

//рассчитываем приведенную цену по цене с приоритетом и по процентам таблицы приоритетов
    RecordSet.ВыполнитьИнструкцию("if object_id('tempdb..#tempcp') is not null drop table #tempcp");
    
    ТекстЗапроса = "
    |SELECT OM_ContPrices.* INTO #tempcp
    |FROM OM_ContPrices
    |INNER JOIN OM_Prices (NOLOCK) ON OM_ContPrices.IdPrice = OM_Prices.Id AND :Пользователь = OM_Prices.UserId
    |WHERE Prior = 1
    |";
    
    RecordSet.УстановитьТекстовыйПараметр("Пользователь", глПользователь);

RecordSet.ВыполнитьИнструкцию(ТекстЗапроса);
    
    ТекстЗапроса = "
    |UPDATE OM_ContPrices
    |Set AdjPrice = CASE WHEN OM_Prior.Perc IS NULL THEN Price ELSE OM_ContPrices.Price + OM_ContPrices.Price*OM_Prior.Perc/100 END
    |FROM OM_ContPrices
    |INNER JOIN OM_Prices (NOLOCK) ON OM_ContPrices.IdPrice = OM_Prices.Id AND :Пользователь = OM_Prices.UserId
    |LEFT JOIN OM_Prior ON OM_ContPrices.Type = OM_Prior.Type AND OM_Prices.SupplierId = OM_Prior.SupplierId
    |";
    
    RecordSet.УстановитьТекстовыйПараметр("Пользователь", глПользователь);
    
    RecordSet.ВыполнитьИнструкцию(ТекстЗапроса);
    
    //устанавливаем признак прохождения цены по процентам (цена с приоритетом и так его прошла)
    //при выборке остается сортировать по этому признаку и цене
    ТекстЗапроса = "
    |UPDATE OM_ContPrices
    |SET CondPrice = CASE WHEN Темп.Price IS NULL THEN 0 ELSE CASE WHEN OM_ContPrices.AdjPrice < Темп.Price THEN 1 ELSE 0 END END
    |FROM OM_ContPrices
    |LEFT JOIN #tempcp AS Темп ON OM_ContPrices.GoodsId = Темп.GoodsId
    |INNER JOIN OM_Prices (NOLOCK) ON OM_ContPrices.IdPrice = OM_Prices.Id AND :Пользователь = OM_Prices.UserId
    |LEFT JOIN OM_Prior ON Темп.Type = OM_Prior.Type AND OM_Prices.SupplierId = OM_Prior.SupplierId
    |WHERE OM_ContPrices.AdjPrice <> 0
    |AND OM_ContPrices.CondPrice = 0
    |";
    
    RecordSet.УстановитьТекстовыйПараметр("Пользователь", глПользователь);

.....

(27) "как ни удивительно но второй параметр от этого то же не спасает. "

Почему это не спасает? Сортировка идет по идентификаторам, все красиво.

(29) Вот именно поэтому вас к восьмерке подпускать не надо.

(31) Иди переписывай. Этот код во сто крат быстрее.

(32) Поговори мне еще тут, дятел с умным лицом.
Восьмерки придумали, чтобы дать возможность программисту управлять местом выполнения (SQL, С1С, Клиент).

Этот код может выполняться быстрее у тебя на локалке, максимум в разы, и он же встанет колом при 20 пользователях. На типовой УПП, где SQL и так захлебывается от типового кода и толпы регистров при проведении.

(33) Пропукался? Местом выполнения гришь? Когда руки из ЖПО всегда что-то не так...

(34) Херачить все на сервере - это специальная рекомендация для динозавров 7.7, по принципу "меньшее зло", дабы они реквизиты через точку на клиенте не тащили, как привыкли в семерке.

(25) а если просто свернуть и сразу найти все строки?

(35) Чья рекомендация?
Я сам понимаю что и как лучше сделать.

(36) Не рассказывай ему только что это можно еще и одним пакетным запросом получить, на сервере. Пусть крутит построчно свои ТЗ.

(36) Можно и так, но это медленнее.

(39) у тебя всё равно по строковому представлению сортируется

+(40) это не всегда удачно

(40) Почему? Строчку кода, где идет сортировка по ст. представлению

(42) у тебя ссылки, а не объекты

(43) Да, ссылки. Ииии?

(44) по идентификатору сравниваются отнотипные объекты, ты СП читал?

однотипные*

(29) Термин масштабируемость Вам знаком?

(47) Мне знакомо утром стулья - вечером деньги.
Предлагаете помочь УПП, посылая еще 100 лишних запросов?

(46) Колонка "Продукция" вполне однотипна. Где ты там разные типы нашел.

(48) Если значение данного термина Вам не знакомо, я снимаю свой вопрос. Спасибо.

Самый смак ситуации в (0) - запросы быстрые, в top не попадут. Но их дохера.

(50) Я не понимаю чем мешает масштабируемости локальная временная таблица. За сим предлагаю закончить пустопердения.

(51) Самый смак в том, что для больших показных внедрений, с овер 5000 юзверей и "масштабируемостью" все вхлам переписывается.  Иначе не взлетит "типовая УПП".

(49) еще раз внимательно читай

(54) Прочитал еще раз. Где там разные типы?

(52) Да. Вам тут не место.

(55) однотипные объекты, а у тебя однотипные ссылки

(56) Конечно, это же Ваша тема :)

(57) Ты запутался. Там идет речь не о ДокументОбъект, а о ДокументСсылка. Именно ДокументСсылка понимается под объектом, можешь проверить профайлером.

(59) в СП написано объекты, а остальные по строковому, не я СП писал

(60) Тяжко вам наверное живется.

(52)
"куярить все на сервере"
"чему тебя в школе учили ..., ковыряться в ТЗ на клиенте?"

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

(62) А как на УФ она обеспечивается? Там всё на сервере.

(63) ТонкийКлиент тоже на что-то годен, но гораздо меньше.

(63) "Там все" на сервере 1С, а пациент (52) пихает сервер SQL.

(10) А чо, в запросе отсортировать не судьба?

(25) Юзер тебе скажет: "Хочу чтобы продукция была в алфавитном порядке" - и оптимизация в пролете.

(66) Иногда не судьба.

(66) Не скажет.

Не занудствуй.

(68) У меня в большинстве случаев Сортировать() используется для ТЗ, которые пользователь так или иначе увидит, т.е. требуется сортировка по строковому представлению.

Hеба утpеннего стяг...
В жизни важен пеpвый шаг.
Слышишь: pеют над стpаною
Ветpы яpостных атак.


В СП ошибка.

Читаем:

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

АВотНет.

Когда не задано СравнениеЗначений идет тупое сравнение по представлению, без учета кода типа, при этом, например, контрагент и организация будут вразнобой, при этом, при одинаковом наименовании они будут раскиданы по колонке стохастически.

Когда это СравнениеЗначений задано - идет сравнение по коду типа и по идентификатору, самая мякотка. Контрагенты в начале списка, упорядочены, потом Организации. Сторого детерминированны. :-)

(0) Вы правда рассчитывали в этом случае получить сортировку по гуидам?
Или как?

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

(72) Там все хуже)

Помимо запросов к СУБД могут еще и обработчики на встроенном языке вызываться - которые ОбработкаПолученияПредставления и второй, в паре с этим работающий.

С учетом этого, а также с учетом того, что для значения в одной колонке могут быть очень разного типа (например, в первой строке - СправочникСсылка, во второй - Число, в третьей - РегистрСведенийНаборЗаписей, в четвертой - ОбъектМетаданных) - даже не представляю, как можно было бы написать в этом случае получение всех представлений одним запросом.

(73) "Помимо запросов к СУБД могут еще и обработчики на встроенном языке вызываться - которые ОбработкаПолученияПредставления и второй, в паре с этим работающий. "

ниче не понял.


С учетом этого, а также с учетом того, что для значения в одной колонке могут быть очень разного типа (например, в первой строке - СправочникСсылка, во второй - Число, в третьей - РегистрСведенийНаборЗаписей, в четвертой - ОбъектМетаданных) - даже не представляю, как можно было бы написать в этом случае получение всех представлений одним запросом.

Все пишется достаточно просто.

(74) Ну напиши пример кода. Я тебе на входу какую угодно таблицу значений, с какими угодно значениями.
А ты на выходе - такую же ТЗ с представлениями.

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

(75) Мне лениво этой хней заниматься. Но пишется это за конечное время, не больше 2 рабочих дней.

(75) На слабо меня бессмысленно пытаться.

(76) Видимо тому, кто кодил это все в платформе - то же было лениво :)

Но то, что оно работает таким образом - давно известный факт.

(62) Переносом функционала на сервер.
Для тех, кто в танке:
В режиме обычного приложения есть огромное количество механизмов, которые в неявном виде обращаются либо к данным из БД, либо к данным сервера приложения (кэши, параметры сеанса). При работе сложных алгоритмов на клиенте имеем неуправляемые обращения к серверу приложений и СУБД. Каждое такое обращение - это процесс состоящий из:
1. Установка связи с сервером 1С:Предприятия
2. Сервер 1С:Предприятия определяет наименее загруженный рабочий процесс
3. Сеанс и соединение перенаправляются рабочему процессу. Особенно это красочно будет на кластере серверов, когда сеансовые данные начнут ездить между рабочими серверами кластера
4. Рабочий процесс открывает соединение с СУБД и начинает получение данных.
5. Рабочий процесс отдает результат клиенту.

Если выполнение кода происходит на сервере целиком, то:
1. Исключены разрешения имен компьютеров в локальной сети для пунктов 1 и 2 предыдущего списка
2. Исключена миграция сеанса во время выполнения одного вызова сервера
3. Сокращен путь передачи информации за счет того, что данные не перенаправляются на клиента

При достаточном аппаратном обеспечении, алгоритм, выполняемый на сервере приложений всегда отработает быстрее, чем если его запустить на клиенте. Если аппаратных ресурсов не хватает - возникает искушение разгрузить сервер за счет клиентов. Как следствие - каждый новый пользователь системы будет требовать установки в качестве клиентской машины системы стоимостью  
~1000$ В то же время, если не поддаваться искушениям и не г0внокодить - стоимость серверного оборудования, потребного для одного пользователя, удерживается в районе 100-150$. Стоимость компа для нового рабочего места составит 500$ максимум. Итого имеем экономию для каждого рабочего места в районе 350-400$ за рабочее место. При этом работать система будет быстрее.

Есть еще вопросы по масштабируемости?

(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? Я пока пытаюсь понять, ты сам хоть что-то понимаешь, или тупо ссылки копируешь...