Не работает DELETE для "повторяющихся" строк

Здравствуйте, добрые люди!
Долго колупался с ускорением заполнения базы и доколупался до хорошей для меня скорости наполнения, однако без граблей не обошлось, когда я опустил проверки на точность параметров при замене данных получил дублирование для одного набора ключей записей с разной точностью. Исходная тема (Импорт данных из файла в БД) короткая, да и проблема видна когда пытаюсь отладить макрос в самой БД.
Как видно из запроса есть 5 ключевых параметров и пара значимых полей в записи - это значение и его точность.

Чтобы было понятно, чем больше число тем ниже точность.

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

Эта штуковина работает, однако по замыслу авторов для удаления этих записей замена SELECT a.* на DELETE a.* приводит к ошибке "Не возможно удаление записей из указанных таблиц", а справка говорит, что недостаточно прав в пяти вариациях... С чего бы? В свойствах запроса разрешения на удаление есть

0

UPDATE пустого значения - это исключение такое же как у ИНСЕРТ в заполненную ячейку - проходили

Очень странно, не должно быть такого. Может быть у Вас настройки такие

0

Сообщение от Swa111 Очень странно

Если бы было не так, то инструкция ИНСЕРТ не имела бы место быть.
АПДЕЙТ можно выполнить только при наличии строки, ее отсутствие порождает исключение
ИНСЕРТ создает строку и если она уже есть - исключение
Это природа команд

0

про природу Update я с Вами не соглашусь, ибо сам никогда не встречал подобных исключений. Проверил в Access через VBA - исключение нет, просто выставляется свойство RecordsAffected в 0.

0

Сообщение от Swa111 Еще хотелось бы уточнить, перед началом обновления БД Вы начинаете явно транзакцию?

Я перевожу таблицу в режим BATCHOptimistic по окончанию "мероприятий" вставки делаю BATCHUPDATE и возвращаю режим Optimistic.

0

Попробуйте в дополнение явно начать транзакцию и закоммитить ее после всех изменений, возможно в Вашем API есть подобные методы:https://learn.microsoft.com/ru... ethods-ado

0

Сообщение от Swa111 Проверил в Access через VBA

Я работаю в Builder через ADO компоненты с движком Jet, там шаг влево вправо - расстрел через хренову тучу окошек с предупреждением о вставке цилиндра в непотребное место

Добавлено через 6 минут

Сообщение от Swa111 Попробуйте в дополнение явно начать транзакцию и закоммитить ее после всех изменений

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

Добавлено через 26 минут

Сообщение от POJIBOX и особенностей режима тоже не знаю

посмотрел вроде как не сложно можно попробовать...

Добавлено через 32 минуты

Сообщение от POJIBOX Я работаю в Builder через ADO компоненты с движком Jet, там шаг влево вправо - расстрел

Вот это косяк! попробовал АПДЕЙТить пустую базу - нуль ошибок нуль записей, странно но уменя орала раньше в голос

0

Сообщение от POJIBOX Ну раз на слово не верите, посмотрите, не знаю что вам может сказать двоичный формат, в описании формата так и сказано, что он предназначен для машинной обработки При том что данные пакуются нестандартной длиной битов

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

но надо ли формировать колоссальную базу на 10м записей?
может разумнее учитывать требования последующей обработки, группируя по датам или регионам наблюдений?

я это имела ввиду

0

Сообщение от shanemac51 - запоминаете где-то выбранные записи в нужном для аксесс формате. например в текстовом или НТМ формате

Какой смысл - все равно пихать в БД (или сначала в файл а потом в БД)?

Сообщение от shanemac51 может разумнее учитывать требования последующей обработки, группируя по датам или регионам наблюдений?

А я что сделал? выбрал нужные данные из нужных источников, для нужных районов, в нужное время, как это еще оптимизировать можно? И естественно по запросу пользователя я представляю ему результаты обработки по конкретной задаче на конкретное время

Добавлено через 5 минут
Такс, проверил вариант try INSERT catch UPDATE, работает только при строгом индексе по 5 основным полям: - не советую 8 минут против 4 на чистую базу, при обновлении данных даже пробовать не буду и так понятно проще очистить от мусора и динамически добавлять - удалять индекс.

0

Какой смысл - все равно пихать в БД (или сначала в файл а потом в БД)?

Собственно с SQLite я так и сделал по сути. В целом не понятно сколько из этих 4 минут занимает чтения и декодирование самих файлов, а сколько вставка в БД.

0

А на клиенте не пробовали делать проверку "дублей" метрик импорта перед добавлением в БД?

0

Сообщение от Swa111 В целом не понятно сколько из этих 4 минут

Таки если тупо пихать в чистую базу все подряд - это 2 минуты. Т.е. расшифровка точно не более 2 минут остальное возня с БД

Добавлено через 1 минуту

Сообщение от Jamaica А на клиенте не пробовали делать проверку "дублей"

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

0

Сообщение от POJIBOX Таки если тупо пихать в чистую базу все подряд

Вот перед "пиханием все подряд", проверить импортируемые метрики,
и пихать/править только нужные?

0

Сообщение от Swa111 SQL 1 DROP INDEX IX ON Weather;

а ежели его еще нет - исключение или пофиг?

Добавлено через 3 минуты

Сообщение от Jamaica проверить импортируемые метрики

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

Добавлено через 2 минуты

Сообщение от Jamaica Вот перед "пиханием все подряд", проверить импортируемые метрики, и пихать/править только нужные?

наверное это близко по смыслу

Сообщение от POJIBOX Такс, проверил вариант try INSERT catch UPDATE, работает только при строгом индексе по 5 основным полям: - не советую 8 минут против 4 на чистую базу

Про построчный UPDATE больше слышать не хочу

Добавлено через 6 минут
А еще забыл добавить я сжимаю БД после работы и это входит во время но там не больше 10 секунд

Добавлено через 1 минуту

Сообщение от POJIBOX а ежели его еще нет - исключение или пофиг?

проверил исключение, а как проверить есть ли индекс?

0

Сообщение от POJIBOX значит нужно хранить импортируемые данные во временной таблице и потом в 3 захода объединять и чистить временную таблицу

Аккурат от этого я считаю можно уйти, если будет адекватное время исполнения.
1. Поднимаем рекордсет на основную таблицу, читаем ее, и и запихиваем метрики в коллекцию Rows
в виде инстансов класса Row.
2. При поступлении новой метрики от парсера, проверяем коллекцию Rows на наличие дубликатов
с новой метрикой (по 5 полям).
2.1. При отсутствии метрики в коллекции, создаем для нее инстанс Row, и добавляем в коллекцию Rows.
2.2.1 При наличии дубля, анализируем остальные поля, если новая метрика нам интереснее имеющейся,
правим значения полей в имеющемся инстансе Row, UPDATE старой метрики в таблице, новую метрику не добавляем.
2.2.2 При наличии дубля, анализируем остальные поля, если новая метрика нам неинтересна - пропускаем.

По завершении работы парсера (кончились новые метрики), мы имеем в коллекции Rows набор метрик и старых, и новых,
но уже очищенных от дублей как внутри самого импортируемого пакета, так и с учетом имеющихся в Weather.
Остается данные "новых" метрик загнать в рекордсет и UpdateBatch.

То есть не нужна таблица Import, не нужны запросы на чистку, и в Weather, теоретически не нужен составной индекс,
только ключевое поле.

Я имитировал такое решение, время исполнения дольше чем штатным DAO, но в принципе приемлемое.

0

а ежели его еще нет - исключение или пофиг?

Если есть возможность то проверить код ошибки. Если код о том что индекс не существует, то безмолвно продолжить дальше, если что то другое - то ошибка БД.

проверил исключение, а как проверить есть ли индекс?

По идее даже если он и был до начала операции, дроп должен был его удалить. Если падает с ошибкой значит что то не так с бд.

Таки если тупо пихать в чистую базу все подряд - это 2 минуты

Как то все грустно с этим JET. Я конечно понимаю что на переправе коней не меняют. Но 2 минуты это много. Попробовал быстренько накидать на питоне программку так там вставка из CSV (Как бы эмулируем уже декодированные данные) с акутализацией даже всего массива данных на 600к строк занимает около 2-5 сек.

0

Сообщение от Swa111 так там вставка из CSV (Как бы эмулируем уже декодированные данные)

Так это декодированные, а время декодирования и записи в CSV?

0

Сообщение от Swa111 Как то все грустно с этим JET.

Со стороны, да.
Внутри штатным DAO вполне шустро.

0

Сообщение от Jamaica Я имитировал такое решение, время исполнения дольше чем штатным DAO, но в принципе приемлемое.

Блин, я уже говорил, тупое раскодирование и пихание в пустую таблицу - 2 минуты, на все про фсе с очисткой, сжатием без индекса 4 минуты, с индексом 6 (но не уверен, что это не результат какой-нибудь подставы).
Над чем мы сейчас бьемся? из 2 минут мы не вылезем никак! это тупо минимальнейшее время все остальное требует ресурсов в конечном итоге сводящих результат потуг на минимум

0

Так это декодированные, а время декодирования и записи в CSV?

Как оптимизировать декодирование GRIB это уже выходит за рамки этого топика. Я уверен что у SQLite есть библиотеки для встраивания и под Ваш язык. Просто дергаем подготовленный запрос на Insert. Я использовал CSV как эмулятор декодера.

Добавлено через 4 минуты

Сообщение от POJIBOX Блин, я уже говорил, тупое раскодирование и пихание в пустую таблицу - 2 минуты, на все про фсе с очисткой, сжатием без индекса 4 минуты, с индексом 6 (но не уверен, что это не результат какой-нибудь подставы). Над чем мы сейчас бьемся? из 2 минут мы не вылезем никак! это тупо минимальнейшее время все остальное требует ресурсов в конечном итоге сводящих результат потуг на минимум

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

0

Можно конечно определить потолок скорости вычистив все операции с БД и оставив только распаковку и формирование строк, но все это муторно... что даст?

0