Как правильно проверить дубликаты в ТабличнойЧасти документа?
В ТабличнойЧасти документа могут быть одинаковые "Наименования". Но, при этом должны различаться "Комментарием". А вот с одинаковыми Наименованиями/Комментарием не должно быть. Как правильно осуществить контроль/проверку?
В процедуру ПередЗаписьюНаСервере выгрузить ТЧ в ТЗ колонками "Номенклатура" и "Комментарий". В третью колонку проставить 1, затем сгруппировать по первым двум суммируя по третьей и если в оставшихся строках будет >1 сообщить пользователю "Наименование/Комментарий" и отказать в записи.
Или есть способ лучше?
В процедуру ПередЗаписьюНаСервере выгрузить ТЧ в ТЗ колонками "Номенклатура" и "Комментарий". В третью колонку проставить 1, затем сгруппировать по первым двум суммируя по третьей и если в оставшихся строках будет >1 сообщить пользователю "Наименование/Комментарий" и отказать в записи.
Или есть способ лучше?
Найденные решения
(1)
Как мы можем искать?
Ну можем просто пробегать по всем строкам - это О(Н), т.е. мы гарантированно выполним алгоритм на Н итераций, где Н = количество элементов.
Умные существа придумали разные виды оптимизации. Самый простой - двоичный поиск. Но для его работы нужен упорядоченный список, тогда, деля список пополам, мы придем у нужной строке уже за О(логарифм по основанию два из Н). На миллион записей у нас О будет около 20. Эффективно? Несомненно! Кстати, двоичный поиск часто объясняют на примере словаря: нужно слово "тратата", оно где-то в центре, открываем словарь, смотрим, а там слова на букву "о" - листаем вправо. Там на "с" - еще вправо, там на "ф" - влево. Никто не листает словарь по странице.
Но как быть с неупорядоченными списками? Типа давайте найдем слово "Голова" в Евгении Онегине. Да, задача сразу усложняется )))
Так как? Умные существа покумекали и предложили несколько вариантов.
Первый - это построение дерева при добавлении новой строки. Т.е. при добавлении ищется место, куда вставить строку. Как ищется? Ну как в словаре - двоичным поиском. Но мы теряем на добавлении, т.е. добавлять мы будем уже не за О(1) как раньше, а за О(логарифм по основанию два из Н).
Умные люди покумекали еще раз. И придумали хеш-таблицы. Суть в том, что на основании добавляемых данных рассчитывается по какой-то функции некий хеш - число. Но это число должно быть в пределах разумного, т.к. становится индексом (порядковым номером, если вдруг кто забыл, что такое "индекс") строки. Так что мд5 не подойдет. Ну или подойдут первые 10 бит, а может быть 16, а может быть 24... Ну как пойдет.
В итоге при вставке в хеш-таблицу вычисляется индекс, но это приводит к тому, что расходуется много памяти. Ну и коллизии, когда для разных значений одинаковый хеш - это прям беда. Но на небольших списках это работает отлично, т.е. позволяет вставлять и получать строку при идеальном положении меркурия за О(1).
В 1С хеш-таблица - это соответствие. Но нужно понимать, что при вставке в соответствие большого количества элементов он будет несколько раз менять размер хеш-таблицы, что приведет к задержкам на вставке значения.
И вообще по поводу индексов, то время их создания не нулевое. Так что на таблицах до сотни записей есть мнение, что обычный поиск по структуре в неиндексированной таблице в итоге не превысит время создания индекса. И есть мнение, что даже для таблицы в тысячу записей это не будет сильно дольше.
Но как бы всегда можно проверить.
Ну и не стоит списывать со счетов какое-нить "выбрать различные" языка запросов, ибо скуль за нас хеш-таблицу построит и все свернет. И если таблица большая, то может быть ну его, а? )))
Или есть способ лучше?
Ну любой способ - это способ. Лучший способ - это минимальное время + минимальный расход памяти.
Как мы можем искать?
Ну можем просто пробегать по всем строкам - это О(Н), т.е. мы гарантированно выполним алгоритм на Н итераций, где Н = количество элементов.
Умные существа придумали разные виды оптимизации. Самый простой - двоичный поиск. Но для его работы нужен упорядоченный список, тогда, деля список пополам, мы придем у нужной строке уже за О(логарифм по основанию два из Н). На миллион записей у нас О будет около 20. Эффективно? Несомненно! Кстати, двоичный поиск часто объясняют на примере словаря: нужно слово "тратата", оно где-то в центре, открываем словарь, смотрим, а там слова на букву "о" - листаем вправо. Там на "с" - еще вправо, там на "ф" - влево. Никто не листает словарь по странице.
Но как быть с неупорядоченными списками? Типа давайте найдем слово "Голова" в Евгении Онегине. Да, задача сразу усложняется )))
Так как? Умные существа покумекали и предложили несколько вариантов.
Первый - это построение дерева при добавлении новой строки. Т.е. при добавлении ищется место, куда вставить строку. Как ищется? Ну как в словаре - двоичным поиском. Но мы теряем на добавлении, т.е. добавлять мы будем уже не за О(1) как раньше, а за О(логарифм по основанию два из Н).
Умные люди покумекали еще раз. И придумали хеш-таблицы. Суть в том, что на основании добавляемых данных рассчитывается по какой-то функции некий хеш - число. Но это число должно быть в пределах разумного, т.к. становится индексом (порядковым номером, если вдруг кто забыл, что такое "индекс") строки. Так что мд5 не подойдет. Ну или подойдут первые 10 бит, а может быть 16, а может быть 24... Ну как пойдет.
В итоге при вставке в хеш-таблицу вычисляется индекс, но это приводит к тому, что расходуется много памяти. Ну и коллизии, когда для разных значений одинаковый хеш - это прям беда. Но на небольших списках это работает отлично, т.е. позволяет вставлять и получать строку при идеальном положении меркурия за О(1).
В 1С хеш-таблица - это соответствие. Но нужно понимать, что при вставке в соответствие большого количества элементов он будет несколько раз менять размер хеш-таблицы, что приведет к задержкам на вставке значения.
И вообще по поводу индексов, то время их создания не нулевое. Так что на таблицах до сотни записей есть мнение, что обычный поиск по структуре в неиндексированной таблице в итоге не превысит время создания индекса. И есть мнение, что даже для таблицы в тысячу записей это не будет сильно дольше.
Но как бы всегда можно проверить.
Ну и не стоит списывать со счетов какое-нить "выбрать различные" языка запросов, ибо скуль за нас хеш-таблицу построит и все свернет. И если таблица большая, то может быть ну его, а? )))
Поиск в цикле
Объявите вспомогательную коллекцию, например, соответствие, где ключ это "наименование + коммент" (можно структурой), значение, к примеру, булевное "истина".
На каждой итерации цикла проверяйте вхождение ключа в соответствие.
Если Неопределено - значит, такая пара встретилась впервые, помещаете в соответствие и следующая итерация цикла.
Если <> Неопределено, значит, пара встретилась повторно, далее как вам надо.., можно в другое соответствие "дублей" вставить
После цикла анализируете коллекцию "дублей"
Объявите вспомогательную коллекцию, например, соответствие, где ключ это "наименование + коммент" (можно структурой), значение, к примеру, булевное "истина".
На каждой итерации цикла проверяйте вхождение ключа в соответствие.
Если Неопределено - значит, такая пара встретилась впервые, помещаете в соответствие и следующая итерация цикла.
Если <> Неопределено, значит, пара встретилась повторно, далее как вам надо.., можно в другое соответствие "дублей" вставить
После цикла анализируете коллекцию "дублей"
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) Не годится. При добавлении по Номенклатуре проверяется. Выдается сообщение. И дубликаты допускаются. Лишь бы Комментарии отличались. Условно: Добавил номенклатуру "Труба". В комментариях ничего не прописал. Добавил опять "Труба", сообщил, что уже такая есть. При проведении - не дает. Но, стоит только прописать Комментарии, у первого на "Куст 1", у второго на "Куст 2" - все корректно проводится.
(1)
Как мы можем искать?
Ну можем просто пробегать по всем строкам - это О(Н), т.е. мы гарантированно выполним алгоритм на Н итераций, где Н = количество элементов.
Умные существа придумали разные виды оптимизации. Самый простой - двоичный поиск. Но для его работы нужен упорядоченный список, тогда, деля список пополам, мы придем у нужной строке уже за О(логарифм по основанию два из Н). На миллион записей у нас О будет около 20. Эффективно? Несомненно! Кстати, двоичный поиск часто объясняют на примере словаря: нужно слово "тратата", оно где-то в центре, открываем словарь, смотрим, а там слова на букву "о" - листаем вправо. Там на "с" - еще вправо, там на "ф" - влево. Никто не листает словарь по странице.
Но как быть с неупорядоченными списками? Типа давайте найдем слово "Голова" в Евгении Онегине. Да, задача сразу усложняется )))
Так как? Умные существа покумекали и предложили несколько вариантов.
Первый - это построение дерева при добавлении новой строки. Т.е. при добавлении ищется место, куда вставить строку. Как ищется? Ну как в словаре - двоичным поиском. Но мы теряем на добавлении, т.е. добавлять мы будем уже не за О(1) как раньше, а за О(логарифм по основанию два из Н).
Умные люди покумекали еще раз. И придумали хеш-таблицы. Суть в том, что на основании добавляемых данных рассчитывается по какой-то функции некий хеш - число. Но это число должно быть в пределах разумного, т.к. становится индексом (порядковым номером, если вдруг кто забыл, что такое "индекс") строки. Так что мд5 не подойдет. Ну или подойдут первые 10 бит, а может быть 16, а может быть 24... Ну как пойдет.
В итоге при вставке в хеш-таблицу вычисляется индекс, но это приводит к тому, что расходуется много памяти. Ну и коллизии, когда для разных значений одинаковый хеш - это прям беда. Но на небольших списках это работает отлично, т.е. позволяет вставлять и получать строку при идеальном положении меркурия за О(1).
В 1С хеш-таблица - это соответствие. Но нужно понимать, что при вставке в соответствие большого количества элементов он будет несколько раз менять размер хеш-таблицы, что приведет к задержкам на вставке значения.
И вообще по поводу индексов, то время их создания не нулевое. Так что на таблицах до сотни записей есть мнение, что обычный поиск по структуре в неиндексированной таблице в итоге не превысит время создания индекса. И есть мнение, что даже для таблицы в тысячу записей это не будет сильно дольше.
Но как бы всегда можно проверить.
Ну и не стоит списывать со счетов какое-нить "выбрать различные" языка запросов, ибо скуль за нас хеш-таблицу построит и все свернет. И если таблица большая, то может быть ну его, а? )))
Или есть способ лучше?
Ну любой способ - это способ. Лучший способ - это минимальное время + минимальный расход памяти.
Как мы можем искать?
Ну можем просто пробегать по всем строкам - это О(Н), т.е. мы гарантированно выполним алгоритм на Н итераций, где Н = количество элементов.
Умные существа придумали разные виды оптимизации. Самый простой - двоичный поиск. Но для его работы нужен упорядоченный список, тогда, деля список пополам, мы придем у нужной строке уже за О(логарифм по основанию два из Н). На миллион записей у нас О будет около 20. Эффективно? Несомненно! Кстати, двоичный поиск часто объясняют на примере словаря: нужно слово "тратата", оно где-то в центре, открываем словарь, смотрим, а там слова на букву "о" - листаем вправо. Там на "с" - еще вправо, там на "ф" - влево. Никто не листает словарь по странице.
Но как быть с неупорядоченными списками? Типа давайте найдем слово "Голова" в Евгении Онегине. Да, задача сразу усложняется )))
Так как? Умные существа покумекали и предложили несколько вариантов.
Первый - это построение дерева при добавлении новой строки. Т.е. при добавлении ищется место, куда вставить строку. Как ищется? Ну как в словаре - двоичным поиском. Но мы теряем на добавлении, т.е. добавлять мы будем уже не за О(1) как раньше, а за О(логарифм по основанию два из Н).
Умные люди покумекали еще раз. И придумали хеш-таблицы. Суть в том, что на основании добавляемых данных рассчитывается по какой-то функции некий хеш - число. Но это число должно быть в пределах разумного, т.к. становится индексом (порядковым номером, если вдруг кто забыл, что такое "индекс") строки. Так что мд5 не подойдет. Ну или подойдут первые 10 бит, а может быть 16, а может быть 24... Ну как пойдет.
В итоге при вставке в хеш-таблицу вычисляется индекс, но это приводит к тому, что расходуется много памяти. Ну и коллизии, когда для разных значений одинаковый хеш - это прям беда. Но на небольших списках это работает отлично, т.е. позволяет вставлять и получать строку при идеальном положении меркурия за О(1).
В 1С хеш-таблица - это соответствие. Но нужно понимать, что при вставке в соответствие большого количества элементов он будет несколько раз менять размер хеш-таблицы, что приведет к задержкам на вставке значения.
И вообще по поводу индексов, то время их создания не нулевое. Так что на таблицах до сотни записей есть мнение, что обычный поиск по структуре в неиндексированной таблице в итоге не превысит время создания индекса. И есть мнение, что даже для таблицы в тысячу записей это не будет сильно дольше.
Но как бы всегда можно проверить.
Ну и не стоит списывать со счетов какое-нить "выбрать различные" языка запросов, ибо скуль за нас хеш-таблицу построит и все свернет. И если таблица большая, то может быть ну его, а? )))
Поиск в цикле
Объявите вспомогательную коллекцию, например, соответствие, где ключ это "наименование + коммент" (можно структурой), значение, к примеру, булевное "истина".
На каждой итерации цикла проверяйте вхождение ключа в соответствие.
Если Неопределено - значит, такая пара встретилась впервые, помещаете в соответствие и следующая итерация цикла.
Если <> Неопределено, значит, пара встретилась повторно, далее как вам надо.., можно в другое соответствие "дублей" вставить
После цикла анализируете коллекцию "дублей"
Объявите вспомогательную коллекцию, например, соответствие, где ключ это "наименование + коммент" (можно структурой), значение, к примеру, булевное "истина".
На каждой итерации цикла проверяйте вхождение ключа в соответствие.
Если Неопределено - значит, такая пара встретилась впервые, помещаете в соответствие и следующая итерация цикла.
Если <> Неопределено, значит, пара встретилась повторно, далее как вам надо.., можно в другое соответствие "дублей" вставить
После цикла анализируете коллекцию "дублей"
(11)
Ну и вишенка - как будешь сообщать информацию о дублирующихся строках, если ты их удаляешь? Ну, например, интересует информация про номера строк-дублей.
Ну и удалять строки при наличии дублей
А по каким критериям? Какую строку будешь оставлять, а какую удалять?
Ну и вишенка - как будешь сообщать информацию о дублирующихся строках, если ты их удаляешь? Ну, например, интересует информация про номера строк-дублей.
(10)
И почему именно копию? Что такое копия - 1) копирование структуры 2) отбор строк 3) создание новых строк 4) заполнение новых строк значениями отобранных
Все еще уверен, что именно копия спасет отца русской демократии?
далее в цикле получать копию таблицы с отбором по ключевым полям.
Где возьмешь наборы значений для этих ключевых полей, чтобы прогнать их в цикле?
И почему именно копию? Что такое копия - 1) копирование структуры 2) отбор строк 3) создание новых строк 4) заполнение новых строк значениями отобранных
Все еще уверен, что именно копия спасет отца русской демократии?
Как вариант. Пойти на сервер. Выгрузить 2 колонки ТЧ в ТЗ. В ТЗ, добавить числовую колонку. Свернуть ТЗ. Пробежаться по ТЗ, в строках где в числовой колонке больше 1, там и есть задвоение.
Так же Кусты напоминают измерения, может создать такой справочник, и в документе вместо комментария выбирать Куст...
Так же Кусты напоминают измерения, может создать такой справочник, и в документе вместо комментария выбирать Куст...
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот