Melkij, я когда экономил undo-segment в Оракле такое делал. Но это вобщем все технические кейсы. Реально - транзакция должна ограничиваться только business rules.
Я так понимаю что если у Постгреса нету undo-segment (у него собсно таблица и есть этот сегмент) то и проблемы такой нету.
Melkij, если у автора есть partitioning можно по другому сыграть. Но конечно главный вопрос - какая решается проблема. Вот его беспокоит что 10 млн обновляются в одной транзакции.
Viktor T2, Нет мне просто интересно. Почему каждый второй?
Давайте так. В этой задаче есть настроечные парамтеры которые оператор или админ или вообще лицо заинтересованное для себя выбирает исходя из понимания бизнес задачи. Например за 30 кадров видео (1 секунда в формате NTSC) вряд ли кто-то принесет новый QR код. Тоесть мы можем вполне себе пропускать 29 кадров и брать 1 первый попавшийся.
Но является ли эта оптимизация достаточной? Да и вообще это оптимизация или просто сознательный пропуск данных? Я считаю что в подобных задачах надо брать совокупность факторов (features). И если вы хотите строить экономную и эффективную систему - надо смотреть в ширину. А не только в частоту кадров.
Viktor T2, неэкономный подход. Он заставляет нас каждый кадр анализировать. Если-бы я дизайнил подобную систему то я разбил-бы ее на некоторые ... каскады чтоли... такой себе термин из радиотехники. Пускай первый каскад анализирует вообще наличие QRCode в кадре. Причем он не обязан его распознавать. Его задача просто сказать что есть наличие или нет. И уже по фронту события не-было-повилось включать распознаватель.
А насчет базы я согласен. Это вобщем-то шаг самый легкий по энерго-затратам после того что QR код уже распознан.
Мне кажется что в топике поставлены 2 разные проблемы.
1) Восстановление искаженного фото. Где тип искажения - дисторсия (бочка подушка) или просто скос skew
или произвольный разворот или другие линейные действия с хорошей камерой без бочки.
2) Собственно распознавание таблиц с трешем вроде точка-запятая или микс 6-8-9 в одну цифру.
Мне интересная первая проблема. Потому что со второй все ясно. Садим наборщиков и они верстают вручную или редактируют.
Никита Савченко, ты сидишь с часами на руке. Или в телефоне. Вот как только система ребутнулась - иди в логи и опубликуй оттуда нам сюда хотя-бы последние 20 сообщений по времени ребута.
JRBRO, это сложная библиотека. Он еще месяц будет разбираться что и как. А тут надо рисовать. Любой дизайнер нарисует векторную картинку карточки в SVG/PDF или издательских форматах. А задача автора будет - просто наложить на нее несколько слоев реквизитов. Номер карты, кому выдана e.t.c. Я не спец в рисовании на Python но тут можно поискать в стековер https://stackoverflow.com/questions/13287028/send-...
В этих ботах есть логгирование? ХЗ. Ну пускай автор еще добавит следующее
Ну и insert подправить соотвественно с этими ненужными кавычками.