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

Конкурс на лучший алгоритм. Из любой, абсолютной любой ТЗ получить список дублей.
Определить, вычленить, убрать - да что угодно то и делайте. Главное что это их очень быстро определит и не каким то выборками, переборками таблицы. Никаких там НайтиСтроки, Свернуть и прочая тормознутая фигня.

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

Берется любая ТЧ / ТЗ (в которой есть колонка Номер строки). Кидаем в запрос.

В запросе перечень каких то полей - критериев. Например - номенклатура, но могут быть абсолютно любые.

А чтобы впоймать дубли все что нужно сделать это

|    МИНИМУМ(ВременнаяТаблица.НомерСтроки) КАК НомерСтрокиМин,
|    МАКСИМУМ(ВременнаяТаблица.НомерСтроки) КАК НомерСтрокиМакс

Так вот. Там где НомерСтрокиМин = НомерСтрокиМакс - это не дубли.
А все где <> дубли! Согласно указанным критериям выборки.

Далее вы можете использовать это полученное знание по своему усмотрению.

А если хотите сразу мгновенно получить в результате из всей огромной таблицы - в 100 000 строк только дубли, то в запросе добавляется

|ИМЕЮЩИЕ
|    НЕ МИНИМУМ(ВременнаяТаблица.НомерСтроки) = МАКСИМУМ(ВременнаяТаблица.НомерСтроки)";  

И готово. Работает с бешанной скоростью. В тестил на 100к, 1 миллионе позиций. Все работает секунды.

не, я просто пытаюсь понять он чо там пишет про групировку по полям поиска что ли ? или что то другое ?

(80)+ для удобства юзания из 1С есть https://github.com/rqlite/rqlite
все через http запросы по api
перед этим из макета в темп сохранил и запустил
и юзай
как не нужен shut down ноду(ы)

(81) все тоже самое. не увеличивает расход

(78) ну и что с этого? записи и чтения и работы с базой нет. Поэтому какая пофиг разница СКЛ или не СКЛ для этой задачи. Один хрен тут работа профессора и оперативки.

Да и 1С однопоточная.

Я еще понимаю вопрос если бы был - что многотысячную запись в регисры или чтение. А тут вообще работа с ТЗ в запросе.. На уровне повторов значений в разных количествах строк)

Еще раз напишу - тесты показали ошуительные результаты!!! МИЛЛИСЕКУНДЫ. Что тут еще надо мосх ипать не понимаю.

Веселые истории экран покажет наш

(87) временные таблицы хранятся на диске. Внезапно, да?

(89) >>Я еще понимаю вопрос если бы был - что многотысячную запись в регисры или чтение

Считай что создаётся временный регистр, в него заливаются все твои многотысячные записи, а потом выполняется запрос по этому регистру

(91) какой еще нафиг регистр... только что меня дураком назвали, а сам такую хрень пишешь.

(91)
>временные таблицы хранятся на диске. Внезапно, да?
Не всегда

https://xn----1-bedvffifm4g.xn--p1ai/articles/временные-таблицы-3-вопроса/#:~:text=Действительно%2C%20все%20временные%20таблицы%20относятся,обязательно%20будут%20записываться%20на%20диск.

(91) могут и в памяти храниться, внезапно. Это тебе не Navision

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

Все нормально, автор работает с ларьками, там продуктива даже на 50 пользователей не найти, пусть развлекается с ВТ

(93) блиин... Вот куда тебя понесло? У нас тут ларёчная ситуация, файловые базы. А так-то и вся БД может in-memory распологаться

(94) тебе-то откуда знать? Ты документацию отродясь не читал. Тем более по таким тонкостям

(0) наличие колонки "номер строки" - не обязательно.

уже давно можно таблицу пронумемеровать в запросе

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

Ребят ну будьте снисходительны слесарь из Мариуполя. Высшего образования нет. Потуг обучения нет. 40+ лет. И так "Доступно и всерьез" человек оправдывает.

Вот народ же))) Сами хрен кому помогут и ответят)

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

А вам лишь бы желчь лить))) Завидуете просто мне да и все)
В тоже мог бы сказать что вы все неудачники! Потому что я зарабатываю миллион в месяц. а вы нищеброды жалкие. Но этого делать не стану)

Я не обидчивый) А вот у вас зависть что я слесарем был, а вы нет))

Пятнично

Добродетель не упадет на колени перед неумолимой поступью прогресса.

Вы на лекциях сисьски старой училки рассматривали и подрачивали двумя пальцами. А я на заводе трудовые мазоли натирал)

(101) "доступно и всерьез - мордой и в навоз!"©pit

:)
Маньяк может уйти из слесарей, но слесарь из Манька не уйдёт никогда

(106) да ладно, че там в каптерке девочек не было?

(100) У некоторых, после маниакальной фазы не наступает депрессивная. Для них после маниакальной наступает другая маниакальная. Посмотри например на Гений1С.

(109) я в цеху по производству газовых котлов работал) Малярши были) Целый участок.

Жень у тебя масса времени страдать х.ней. Вот реально возьми курсы не обязательно 1С, а лучше совсем не 1С. Java - самое то. Они на все твои умения наложат знания нормального программирования. Они доступны и в возрасте 40+. Как раз на этих курсах дают, что почему то не дают на курсах 1С - на них учат программировать, а не применять в задачах.
Такие курсы дадут тебе нормальный базис, парень ты не глупый, ну не повезло в молодости догоняй в возрасте.

(112) курсы учат программировать?

(112) у меня два студента) уже вторые курсы проходят за полгода. Думаю не последние)

Мне нафига эти курсы)) Ты знаешь что даже на курсах 1С ничего толкового не учат. Они там до сих пор по старинке сидят одну и туже базовую фигню молотят.
А на специалиста очень много и частно отвлекаются.
Но у меня ребята молодые) таланты. Я им много разных курсов куплю.

Это первое. А второе - раз ты меня считаешь что у меня знания не ахти по 1С. То какого фигли тут бывает вопросы заводишь и ноль толковых ответов. Хотя лица все теже мелькают.

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

И даже в этой теме уже разжеванной чуть ли не сразу и понятной, после того как я объявил тесты и скорость что это все работает 0-1 секунду, кто то усомнился что на СКЛ оно так работать не будет....

Запомните - если что то работает 0-1 секунду, оно не станет вдруг иначе работать в 50 раз хуже.

Как будто в файловой базе не временные файлы... ну уморы.
Уже кто то ляпнул что это регистр создается с временной таблицей...

Судя по всему - регистр сведений))) бугага.

Ато смотри умник на умнике сидит. Слесаря решили учить)

(117) в файловой не нужно тз на скуль передавать и обратно. все на месте происходит.
а если скуль еще и на другом серваке ...

(120) у тебяф запросы где делаются? их на клиенте даже создать невозможно. Любые запросы это сервер.
А файловая не файловая - какая пофиг разница.

И мы тут не про передачу говорим с клиента на сервер или с сервера на клиент. Это вообще отдельная песня.
Что такое для СКЛ передача 100-200 мегабайт. тьфу.

Другое дело что у большинства сервера допотопные. У Гилева даже там процентов 50 тестов на каком то овне 15 летней давности. И я часто вижу у клиентов сервера .... дешевле какого нибудь айфона.
Печатный станок.

Но один хрен оптимизированный запрос. если на 100к ТЗ работает на 2000 дублей меньше секунды. То оно даже на овне никак не станет работать в 50 раз хуже. Ну станет 3 секунды.

(120) и ты тут дико ошибашся что в файлово все на месте происходит. Если какие то данные на форме. То хрена два! Там передача идет и еще какая. с формы в модуль и обратно!

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

А вот кстати если делать переборку дублей. типа свернуть и потом НайтиСтроки и прочая хрень... то это не секунды и даже не 1-2 минуты.

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

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

И также ничего страшного если сама задача никогда не коснется каких то больших данных. Ну фигли там поставить НайтиСтроки где никогда не будет больше 100 строк.
Какая нибудь таблица настроек. Нафига к ней запрос писать.

А вот если серьезные данные то только запросы и запросы.


Вот видите я отлично знаю курсы 1С. там именно так поясняют. Что все нужно использовать от предметной задачи и ситуации. не всегда нужно лепить запрос там где нафиг не надо. но всегда когда мы понимаем что тут будет обьем данных.

А по поводу передачи между формой и сервером и прочее ТЗ и ТЧ уже тема была. Эта хрень мне покоя не дает ужасно.

(116) "Товарищ" Ежов вам не товарищ и смотрит на вас, как манул на репортера.

(131) Репортер Ежов с места событий)

Я иду, куда требует Высшее Благо.

(116) >>Запомните - если что то работает 0-1 секунду, оно не станет вдруг иначе работать в 50 раз хуже

Ну-ну. Я такое сотни раз видел. Написан небрежный запрос, вроде работает нормально, и написан давно. А потом накапливается большой объем данных, и запрос начинает люто тормозить

(134) и что с того что ты видел) Как будто я не видел) или кто то другой тут что то не видел)))

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

Мы тут больше болтаем, чем просто ты мог за 2 минуты накидать обработку с ТЧ и таким запросом. и проверить на чем хочешь. Сложность обработки уровень школота.

Было бы тут прикрепление файлов я бы сам скинул) мне не жалко.
Вошбнику на заметку - что было бы здорово файлы выкладывать 1С формата

Уже бы давно конкуренцию ИС сделал.

(136) Давно бы уже выложил бы на гугл-диск.

(127)
1. Чтобы найти дубли в отсортированной ТЗ ничего сворачивать не надо, делается в один обход цикла.
2. В ТЗ можно тоже индексы и тогда множественный поиск не будет занимать минуты...

(140) действительно множественный поиск нужно делать через merge.

(141) Но я ни разу этого ни у кого не видел. И не увижу.

(141) для поиска дублей не нужен мердж, достаточно обычного прохода

(141)(143) Расшифруйте

(144) не знаешь что такое мердж?

(143) Я в целом, понятно, что дубли складываем в hashmap

(145) Нет. Это?
https://ru.wikipedia.org/wiki/Merge_(SQL)

(146) Кстати да, тогда и сортировка не нужна

(147) merge - это алгоритм, как из 2 отсортированных массивов сделать 1 отсортированный

(147) Сортируем 2 таблицы по полям поиска (или берем уже отсортированные) и проходим их в одном цикле, сравнивая по полям поиска и сдвигая указатель по отставшей.

(149) (150) Понятно "сортировка слиянием". Спасибо.

(149) как ты смеешь магистру такое говорить

(151) сортировка слиянием - это уже применение слияния для сортировки. само слияние - оно само по себе

(151) Нет

(154) ну принцип (слияния) вроде тот же. Смысла погружаться в терминологию не вижу, для себя по крайней мере.

(146) Кстати можно Маньяка потроллить)
Женя, это по идее будет быстрее твоих запросов на любых объемах при любых ключах. Для отсортированных ТЗ правда всё горазда проще

(156) Это... скучно.

(156) с хэшмапом не удобно, если несколько полей. нужно как-то составной ключ придумывать

(158) Новый ХэшированиеДанных.

(159) может статься, что сортировка то побыстрее будет, чем хэширование полей по всей таблице

(160) Может. Я хеширование 5+к MD5 строковых полей выносил в ВК. Даже с учетом конвертаций UTF-BSRT-UTF выходило на порядок быстрее, чем встроенным механизмом.

(156) прикол в том что не нужна сортировка. Нужно сохранить порядок.

и второй прикол в том что куда быстрее если миллисекунды работает все, включая даже выборку и перебор строк. А там у меня из 100к - 40к дублей.

Я думаю сортировка ТЗ будет тормознее. Кстати в 1С они тоже тормозной метод.

(162) порядок восстанавливается второй сортировкой

заканчивайте эту тему)

Не нужно страдать там где в этом уже нет необходимости. Из курсов 1С.

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

Вот другая есть задача)))

Как зная теперь дубли и даже номера дублей.

В уникальные дубли ТЗ (зная что это дубли) проставить нужное значение.

а стоп. отмет знаю

(160) на простой ТЗ из одной числовой колонки
При 100к записей сортировка в 3 раза медленней чем вставка+поиск в соответствии.
На 1М записей в 5 раз медленнее.
Это без всяких сериализаций и хешей

(121)[у тебяф запросы где делаются? их на клиенте даже создать невозможно. Любые запросы это сервер.
А файловая не файловая - какая пофиг разница.]

Ну как бы есть разница, какой "движок" это всё обрабатывает - тот, что в скуле, или тот, что в платформе 1с зашит.

(0) выгружаешь в ТЗ, добавляешь колонку Счетчик.
туда пишеть 1000000 + номер строки.
Сворачиваешь по полям, по которым ищешь дубли и суммируешь по Счетчик.
Где счетчик > 1000000 там значит есть дубль, берешь остаток от деления на 1000000, получаешь номер строки.

Возьмем ТЗ, в которой всего две строки
строки являются дублями.
счетчик-1 = 1'000'001
счетчик-2 = 1'000'002
свернули. получили одну строку с "дублем"
счетчик = 2'000'003
берем остаток от деления 1'000'000 = 3
и что нам говорит "номер строки 3"...?
что пора идти в лес..?

(173) в остатке получишь СУММУ номеров строк. Сергей пытается в математику - неожиданно

слово с одной гласной... взбзднуть... ;-)

(174) ну 3 - как раз один из двух вариантов, которые дают конкретные номера строк.

(177) и дальше что?

(178) да ничего
>> и что нам говорит "номер строки 3"...?
Говорит, что нам очень повезло, и дубли в 1й и 2й строке. А вот во всех остальных случаях (кроме 3 и 4) - да, идти в лес.

(174) типичный генизм. Некогда думать, надо хениальные мысли в эфир вываливать

Как-то раз Маня выяснил, что в запрос можно передавать ТЗ...

(181) ТЧ. и то не всегда. если это будет ТЧ объекта то хрен.

(182) Маня, ну не позорься уже вконец что ли
ТЧ ссылки вообще простейшим образом выбирается в запросе
ТЧ объекта - это уже ТЗ
Так что речь именно про ТЗ и только про ТЗ