Если запрос такой проблемный, а число уникальных чеков аддитивно по дням и ТК, то почему бы не сделать пред агрегат по 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. Какие тут минусы?
Тоже давно заметил, что в фоне запущена служба Я.Метро, даже если приложение выключено. Пришлось снести приложение, хотя бы в целях экономии ресурсов телефона.
Обнаружил в базе один из моих email, почта не основная, была зарегана на всякий случай пару лет назад. Использовался только для пересылки почты на gmail, больше нигде пароль не вводил.
Так что ввод пароля на левом сайте исключаю.
Если запрос такой проблемный, а число уникальных чеков аддитивно по дням и ТК, то почему бы не сделать пред агрегат по 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.
Так что ввод пароля на левом сайте исключаю.