Алгоритм проверки схожести двух больших таблиц #722019

Есть две большие таблицы значений. Проверку идентичности делаю по некоторым полям. Посоветуйте оптимальный алгоритм вхождения данных строки из таб1 в таб2

в запрос их И джойном

отсортировать по этим полям и в одном цикле проверять совпадение (количество строк одинаковое)

количество строк может быть разным, как в таб1 так и в таб2

как при этом таблицы могут быть идентичными?)))

ааа, вхождение одной таблицы в другую. все равно один цикл

Сортировка да. Осталось выбрать поля для сортировки.

Кодом или запросом:

счетчик1=1, счетчик2=1. цикл, если счетчик1>малаятаблица.Количество, прерываем цикл (таблицы идентичны) в цикле, если совпадение ключевых полей малой таблицы (индекс счетчик1) и большой (индекс счетчик2), увеличиваем оба счетчика. если же не совпадают, то увеличиваем только счетчик2. если счетчик2 достиг конца большой таблицы, таблицы различны

+1 то, что таблицы всегда разные, это и так понятно. Вот только в чём цель сравнения ТС не озвучил

Регистр бухгалтерии. Движения документа. Необходимо понимать, что проводки документа из базы1 входят в такой же документ из базы2. Сложность в том, что документ с таким же ИД может делать в разных базах отличные движения. Но все это надо слить в одну базу. Примерно так. Немного путанно получилось.

Разные базы: здесь еще есть сложность в определении "одинаковости" справочников, которые сидят в субконто проводок...

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

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

Проще перенести по максимуму с соответствующим признаком. А дальше оператор смотрит и помечает на удалении лишнее. ИМХО, проще чем пытаться угадать, если ты сам в базе не работаешь постоянно.

Кратко. Мне нужно из 15 баз, сделать одну общую. Конфигурации у всех баз идентичны. Нюанс, что в зависимости от базы документ может делать разные движения, а в итоговой общей, они должны аккумулироваться.

Это общая задача. Ну так и переноси с каждой базы со своим префиксом. ИМХО, сабж не соответствует задаче

В этих сводных проводках нужны только: "коды счетов, период и код организации с суммой."? Если в базе 1 есть Проводка1, в базе2 есть Проводка1 (т.е. проводки в этих базах идентичны), то в сводной базе должна быть только одна Проводка1. или их должно быть ДВЕ?

Допустим, что ты удачно сольёшь в одну кучу. А дальше что?

У меня проверка доков по ИД идет. Перенос должен быть онлайн. Постоянно. Задача в том, чтобы понять, что движения документа из базы1 есть в базе2.

"сабж не соответствует задаче" + действительно, не понятно зачем в задаче по сливанию баз нужно СРАВНИВАТЬ? слил все данные без сравнения и всё :)

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

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

У нас от таких сводных отчетов уже в глазах рябит. Это немного другая задача. Нужна общая оборотка для бухгалтеров. Со всеми анализами и т.п.

"Задача в том, чтобы понять, что движения документа из базы1 есть в базе2." При загрузке движений из базы1 (источник) в базу2 (приемник)  нужно: - найти существует ли уже документ, если НЕ существует создаем новый - если существует: УДАЛЯЕМ в нем проводки по организации1 (из базы1). - создаем НОВЫЕ проводки по организации1.

Данных много. Прежде, чем сливать необходима проверка, а нужно ли?

Есть еще база2, база3 ... И по некоторым видам документов эти проводки должны в сводной базе добавиться к уже существующим, а не замениться на свои.

Нужен признак изменения документа. Был изменен документ (после предыдущей загрузки) - грузим его, не было изменений - не грузим.

"Есть еще база2, база3" У них ДРУГИЕ организации в проводках?

Необходимо в плане обмена дописывать тогда.

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

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

можно план обмена сделать новый в каждой базе. Если нет такой возможности, то анализировать в документах реквизит ВерсияДанных: хранить его (в РС например) в сводной базе. Изменился реквизит ВерсияДанных в базе-источнике, значит грузим все движения этого документа в сводную базу.

Наверное, хотят чтобы сводный отчет формировался БЫСТРО, если тянуть данные из 15 разных баз при КАЖДОМ формировании отчета - будут очевидные тормоза :) ИМХО, если сводные отчеты нужны часто и быстро, то сводная база вполне оправданна.

Например так: В каждой базе план обмена с фиксацией изменений у всех документов. Сводная база по регламенту подключается к каждой базе-источнику, читает изменения в плане обмена, грузит проводки в сводный документ (перед загрузкой чистка существующих проводок в базе источнике по документ + организация) PS для этих целей есть готовые конфигурации, можно воспользоваться, чтобы не изобретать велосипед :)

Это гадание на кофейной гуще. ИМХО, быстрее сформировать отчет, чем сначала перенести документы и сформировать отчет. Перенос однозначно дольше. Слово ОНЛАЙН ни о чем не говорит? Или это просто так озвучено?

Фиксация изменений это тоже проверка, что изменились данные важным полям. Эта проверка будет в момент проведения документа, что не очень хорошо.

Про гадание на кофейной гуще согласен:)

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

На закрытых периодах никакого гадания нет.

Угу. Все правильно. В плане обмена у меня настроен регистр бухгалтерии. При изменении табличек все фиксируется.

Озвучь твое понимание "ОНЛАЙН" для этой задачи.

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

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

>8000 проводок При условии сворачивания проводок по кодам счетов и организациям их будет на порядки меньше ;)

Т.е. еженочная регламентная загрузка в сводную базу устроит :)

Зря ты вносишь путаницу в понятия. Вариант наиболее оптимальный. В правилах переноса сделай группировку проводок в нужных разрезах.

Свернуть это мысль) да.

Документы с одинаковым ИД в этом случае придется разделить. Этого делать нельзя.

И про готовые конфигурации не понял? Для всех баз подходит, и не типовых?

Немного в сторону: как в разных базах получаются документы с одинаковым ИД?

Для всех: первым этапом настройки идет чтение структуры внешних баз-источников (в том числе на разных платформах: 77, 8 и т.д.), эта структура хранится в сводной базе (в справочниках).

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

Там регистров бухгалтерских нет?

полуОФФ. Сначала создаются трудности, а теперь успешно преодолеваются.

Есть, сводные документы делают движения именно в бух.регистрах.

У нас бух регистр не типовой. Там измерения доп есть.

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

Опять же: при условии чтения проводок только по Счет/Организация/Сумма какая разница есть ли другие измерения или нет? :)

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

Вы никогда не сталкивались, чтобы документы с одним ид делали разные движения в разных базах?

Там есть понятие: "Источник данных", его можно сделать конструктором или ручным запросом. Запрос в источнике данных может обращаться во внешнюю базу. Т.е. фактически источником данных для загрузки в сводную базу может быть любая таблица/набор таблиц из базы-источника. К типовым конфигурациям привязки нет. Вот только решения по сливанию В ОДИН документ в приемнике разных документов из источника (у документов равны ИД) там точно нет. Т.к. реквизит "Информационная база" - это реквизит шапки документа. А для данной задачи нужно чтобы это был реквизит в регистре бухгалтерии.

Спасибо. Буду смотреть эту базу)

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

1С:Финансист

Документ рождает движения в зависимости от имени базы. В сводной базе придется реализовывать алгоритм этот.

Сделал этот алгоритм. На документе 8000 проводок проверку сделал где-то за минуту. Таких документов немного поэтому пойдет

Не стал сворачивать? :)

+ алгоритм БЕЗ вложеного цикла

у тебя в алгоритме ошибка - он НЕ рабочий!!! Для Каждого СтрокаНаборДвиженийХозрасчетный ИЗ НаборДвиженийХозрасчетный Цикл              НаборДвиженийХозрасчетный.Удалить(СтрокаНаборДвиженийХозрасчетный);

я тут колдую

Можно, но и так быстро работает) За конфу спасибо. Я все задавался вопросом про универсальную систему для сбора данных, теперь буду ковырять.