Как выгрузить ТаблицуЗначений по отбору с условием (зн<0) #643162

Можно ли в выгрузить таблицу значений по отбору По Синтаксису В качестве отбора выступает структура, ("ИмяКолонки", ЗначениеОтбора) Можно ли как то вписать условие в  ЗначениеОтбора, например отобрать все записи <0

да. запрос.

нет. запрос.

куда выгрузить ?

или построитель запроса

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

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

И соответсвенно вызов Новаятз=СкопироватьПоУсловию(Тз,"Стр.НужнаяКолонка<0");

Почему только запросом? Перебор все еще имеет большие силы для этого... :)

Можно другой вариант Функция СкопироватьПоУсловию(Тз,Условие) Массив новый массив;

Перебор это тёмная сторона Силы. Ты должен использовать Запросы, чтобы стать настоящим джедаем.

Блестяще!

а лучше всего запрос в переборе, это сила темной энергии.

Запрос, юные падаваны, ведёт на Светлую Сторону, тогда как необоснованный перебор - на Тёмную. Выбрирай сам.

Насколько я понимаю, ТЗ на 10К строк во время запроса путешествует на сервер, затем на сервер БД, и обратно. Это угодно темной стороне или светлой?

Угу для того, что бы получить результат перебором мало того, что по количеству кода он будет меньше, так еще для запроса нужно таблицу закинуть на сервер приложений, оттуда закинуть на SQL во временную таблицу и дальше таким же макаром обратно. Где тут светлыя сторона?

Накладные расходы на передачу на сервер и обратно несравнимо меньше с выигрышем в скорости при обработке на сервере, чем тупой перебор на клиенте

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

17+ Ну а обработать доже несколько тысяч строк совсем незаметно для пользователя справится и процессор под ДВК 2. Проверено.

у тебя мощность локальной машины равна мощности сервера? Хм... Имхо в консерватории что то не то...

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

продолжай жить в своем мире :)

21 Давай поставим эксперимент с замером времени и будем жить в одном мире. Приведи свои аргументы. Кстати если SQL может распараллелить задачу, то 1С все обрабатывает в однопотоке. Темный твой мир. Кстати если помнишь раньше было модно использовать мощности клиентских машин, для распределенных задач, так как мощностей серверов не хватало.

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

Как то года полтора назад на мисте (может больше, может меньше) была тема - что быстрее - массив или соответствие. Увлеклись. Взяли чью-то базу, закинули все доки в ТЗ. Получилось около полумиллиона документов. Не помню суть эксперимента, но нужно было по какому то простейшему условию отобрать из таблицы доки - делали соответствие, массивы, ТЗ с индексом и без. Кто-то предложил - а если во временную таблицу и запросом? выиграли соответствия и индексированные ТЗ. Проиграл массив. Хуже массива был только запрос на сервер с временной таблицей. Даже условия задачи, полностью выполненные на сервере (т.е. сразу доки без подгрузки в ТЗ по условию отбирались на сервере - все равно временные таблицы проиграли индексированной ТЗ). Правда на 8.1 делали, если это о чем то говорит...

Правильный ответ - it depends. Есть хороший принцип - располагать алгоритмы обработки поближе к данным (а не наоборот). Если наша ТЗ на 100К строк тянется из базы, то там же нужно и отфильтровать, запросом. Если это ТЧ документа на десяток строк, набитая пользователем, можно и на клиенте перебрать, ничего страшного. Тема популярная, кстати.

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

>бинарный поиск в школе учили? Не будь таким требовательным, это же не форум по C++ :) Тут цитируют СП за фотку.

У меня ТСД работает с десятком тысяч строк, где есть и динамическая фильтрация и отборы. Правда там C#, но терминал то на ARM 600 МГ. Ну а если ты о клиенте заботишься давай посчитаем, какую работу он выполнит при вызове на сервере. Работа по сериализации ТЗ состоит из описания колонок, а также проход по всем строкам с сериализацией каждого поля в строку и запись в XML. При получении ответа, нужно пройтись по  XML ответу, десериализовать. То есть ты считаешь, что такая работа значительно меньше затратная чем в 9. То есть пройтись по строкам, вызвать условие записаь ссылк строк в массив, а затем просто скопировать память и увеличить счетчиу ссылок у ссылочных типов? Что то у Вас в консерватории.

Давно пользуюсь группированием таблиц. И тормозов не замечаю. Используя вычислить, можно вычилять любые поля группировок Функция СравнитьПоля(Структ,Строка)

28+ Ах да еще забыл, что если канал узкий то еще желательно данные сжимать.

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

перебор рулит всетаки имхо. создавть запрос, сувать в него тз(кстати предварительно еще переведя ее в ТЗ с типизированными колонками если нет),Потом в ВТ...Потом из ВТ выбирать... Нет ребята. проще и экономичнее перебрать чем следовать моде и канонам.

как я и говорил у вас довольно ограниченный мир. конечно это все "зависит" от объемов данных и все такое, в определенных случаях клиент может отработать быстрее. но вы забываете (а может просто не знаете) что есть такие слова как "масштабируемость" и "клиент-серверное". ну напишите вы код, который анализ будет выполнять на клиенте, и по вашим "детским замерам" это окажется быстрее чем на сервере, потому что размер базы "детский". А что будете делать когда размер базы вырастет в 50 раз? будете переписывать код? или изначально напишите две ветки событий в зависимости от размера таблицы? И откуда вы знаете мощность конкретного клиента? Может это буховский стационарный компЮ а может полудохлый ноут 6-8 летней давности? И напомню (если вы вообще знали), кроме обычного клиента, есть еще и тонкие клиенты, и веб-клиенты. Там тоже всю "эту вашу херню"  будете выполнять?

33 Я тебе приводил пример с ARM, ДВК 2. Многие работают в терминалах и кое где вместе с сервером приложений. А по поводу 6-8 летней давности, то они еще ого го какие быстрые кстати результаты некоторых данных на не топовых машинах девятилетней давности С такими задачами как фильтр, группировка справится любая машина.

+100 только у меня например ситуация еще хуже

Добавить индекс "ИмяКолонки" отсортировать по индексу найти строку где >0 (либо перебором от начала до середины, либо алгоритм "деление пополам ") Скопировать строки

На в 2 раза меньших объемах, чем наши, ЛЮБАЯ стандарнтая умирает

ма рассматривали все и все замеряли

УППырище - это колнечно писссееецц

более 150 регистров сведений

накопления

пардон

около 250 регстров сведений

бльшинство из которых нах никому не нужно и сделано так. ..."на всякий случай"

Кто читал код типовых, тот  меня поймет

КАКМЕ ЖЕ ОНИ УПОРОТЫЕ УКУРКИ ГРЁБАННЫЕ!!!

вот

вотбщем взяли пустуй бух с минимом регистров и наворотов

И ваяем свое.

И всем советую кстати

Это был крик души если что:-)

Извините

Не совсем тебя понял. Конструкцию... ...тоже для масштабируемости надо переписывать на запрос с временной таблицей? А ведь это тоже работа клиента, который может оказаться как тонким, так и веб и т.п. Принципиально ни чем не отличается от перебора ТЗ(полного, бинарного или индексированного) на клиенте с проверкой условия.

давайте исходить из того что на клиенте нет таблиц значений

хотя если в вашем мире они есть - пусть так

Все-таки на вопрос ответишь? У меня нет мира - я сам спрашиваю. Чем принципиально отличается к примеру от конструкции в ?

условия выборки из таблицы не всегда ограничивается > < =

Согласен. А если рассматривать простые условия сравнения?

тогда возможно

Угу прочитай внимательно 28. У тебя на клиенте больше будет действий по сериализации десериализации. При этом будет тот же перебор. В сериализаця полей будет значительно разного рода условий. Опять же для примера итоги по нескольким полям выдает дерево которое нужно обходить по уровням, конечно можно написать рекурсивный вызов, а многие делают вложенные цикла по 6 уровней. Или же можно самому сгруппировать всего в 2 уровня. Ну надо же даже с чем то согласился. В топике как раз то самое простое условие.

на клиенте нет таблиц значений. и все твои доводы пук в лужу.

Как это нет? То есть в неуправляемом (Обычное приложение )приложении нет клиента? Ты о чем? Мне нравится как сделаны динамические фильтры в DataView private void cbLogins_SelectedIndexChanged(object sender, EventArgs e)        { Для того, что бы такого добиться в 1С мне требуется держать две таблицы (одну полную, другую отфильтрованную), и синхронизировать данные.

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

Интересно a к кому адресовано 16?  А для того, что бы сделать запрос тебе нужно передать тз на SQL сервер. Делается это либо через булки создавая текстовый файл, либо через запросы с Insert. Так или иначе все равно нужно пройтись по таблице либо сериализовать в текстовый файл, либо установкой параметров, которые так или иначе сериализутся для передачи на SQL сервер. Где выигрыш?

Кстати мое личное мнение, что должны существовать 2 технологии. Та же УПП это пока обычное приложение. Да и сервер приложений в большинстве случаев лишний костыль. Сейчас мощности КПК вполне достаточно, что бы работать в 2х звенке.

Кстати добавлю еще, что программирование того же клиента на C# для КПК намного проще чем на толстом клиенте, а уж на тонком и подавно. DataView и DataTable достаточно мощны. Нужные надые по максимуму передаются на клиента, используя в том числе статистику. Дополнительные данные в том числе и печать ведется через вызов процедур на клиенте через ВК по TCP/IP. Считай, что это вызов серверных процедур. Но вот тоже, написать на толстом клиенте вызывал у меня рвотный эффект и массу дополнительного времени на программирование той же задачи на 1С.  Управляемые формы легче создавать на том же компакт Фреймворке, а доступ к данным осуществлять через Вэб сервисы со сжатием трафика если это нужно. И опыт такого взаимодействия с сайтом и клиентами дергающими Вэб сервисы  имеется. По сути так устроены управляемые формы. Только мощности КПК хватает для решения всех задач клиента, и сведения вызова сервера к минимуму. Правда с оговоркой, что задачи бывают разные и их легче оптимизировать используя тот же C# используя его мощь.

Ну ты разошеееелся