Если запрос такой проблемный, а число уникальных чеков аддитивно по дням и ТК, то почему бы не сделать пред агрегат по store_id, calendar_dk, plu_group_id и обновлять только дельту дней, которая явно меньше месяца, а в отчете брать сумму за нужный период и нужные ТК?
Oracle BDA позволяет получить доступ к данных hadoop в Oracle или сделать 1 партицию в таблице на данных Hadoop, а другие на данных Oracle. Как это было решено при условии kerberos в кластере hadoop?
А сообщество PG не хочет выпустить книгу по стоимостному оптимизатору? Я бы с удовольствием почитал.
П.с. прошлая статья, почему то, прошла мимо, хотя читаю все из топика базы данных.
Искал в документации по MSSQL, где было бы сказано про NULL и index, чтот нигде не написано.
В Oracle строго оговорено, что по умолчанию NULL не попадает в индекс.
В индексе нет NULL значении, так что он будет ускорять арифметические операции.
В Oracle будет fast full scan index при полном сканировании или range scan при частичном без физического обращения к таблице.
Спасибо за ответ.
Я проверял через online сервис ABBYY, текст и цифры распознаются довольно хорошо. В тексте бывают ошибки, но его проще вручную поправить, главное чтоб число позиций и цены соответствовало чеку.
Мне показалось проблема в том, что все чеки разные: товары, итоги и названия торговых точек раскиданы у кого как, хотя, кажется, все стараются двигаться к одному стандарту.
ZlodeiBaal, подскажите, а задача распознавания чеков по сложности схожа с задачей по ценникам?
Который год хочу заняться, но опыта в этом 0. Не знаю, стоит ли браться.
Странная, конечно, конструкция «ON CONFLICT», лучше уж MERGE использовать, если хочется сделать и insert и update (имхо со стороны разработчика oracle)
Я не понял, в конце вы все таки остановились на варианте с одной таблицей контактов? Причина была только в размере бд? Вы замерили разность скорости выборки из разных таблиц или из одной?
Можно еще было хранить каждый контакт в своей бд, получилось бы своего рода партиционирование на физическом уровне. Осталась бы только проблема с вытаскиванием последнего сообщения при старте.
С OCN не работал, а нельзя для этих целей использовать триггеры на таблицах? В триггере также можно вызывать процедуру или послать сообщение по сети DBMS_TCP. Какие тут минусы?
Тоже давно заметил, что в фоне запущена служба Я.Метро, даже если приложение выключено. Пришлось снести приложение, хотя бы в целях экономии ресурсов телефона.
Не написано о недостатках бездумного увеличения размера фетча: раздутия буфера на бд и клиенте, увеличении нетворк пакета.
Возможно, это значение нужно подбирать от средней потребности клиента?
Если запрос такой проблемный, а число уникальных чеков аддитивно по дням и ТК, то почему бы не сделать пред агрегат по store_id, calendar_dk, plu_group_id и обновлять только дельту дней, которая явно меньше месяца, а в отчете брать сумму за нужный период и нужные ТК?
Для HCC нужна exadata, не всем подойдет
Oracle BDA позволяет получить доступ к данных hadoop в Oracle или сделать 1 партицию в таблице на данных Hadoop, а другие на данных Oracle. Как это было решено при условии kerberos в кластере hadoop?
П.с. прошлая статья, почему то, прошла мимо, хотя читаю все из топика базы данных.
Вот наше все, для понимания стоимостной оптимизации (хоть там и про oracle)
В Oracle строго оговорено, что по умолчанию NULL не попадает в индекс.
В Oracle будет fast full scan index при полном сканировании или range scan при частичном без физического обращения к таблице.
Я проверял через online сервис ABBYY, текст и цифры распознаются довольно хорошо. В тексте бывают ошибки, но его проще вручную поправить, главное чтоб число позиций и цены соответствовало чеку.
Мне показалось проблема в том, что все чеки разные: товары, итоги и названия торговых точек раскиданы у кого как, хотя, кажется, все стараются двигаться к одному стандарту.
П.с. выложил примеры которые насобирал за некоторое время: homebuh.pro/api/ocr/files/demo.homebuh.pro/index.php
Который год хочу заняться, но опыта в этом 0. Не знаю, стоит ли браться.
Смешно это слышать бывшему работнику ГК Систематика.
Можно еще было хранить каждый контакт в своей бд, получилось бы своего рода партиционирование на физическом уровне. Осталась бы только проблема с вытаскиванием последнего сообщения при старте.
Почему бы им не сделать 2 события: beforecommit — ошибка бы откатывала и aftercommit — ошибка не откатывала.
Вообще хватило бы и одного aftercommit.