Алексей Скахин
@pihel
Oracle performance specialist
Information
- Rating
- Does not participate
- Location
- Санкт-Петербург, Санкт-Петербург и область, Россия
- Date of birth
- Registered
- Activity
Oracle performance specialist
Information
П.с. прошлая статья, почему то, прошла мимо, хотя читаю все из топика базы данных.
Вот наше все, для понимания стоимостной оптимизации (хоть там и про 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.
Так что ввод пароля на левом сайте исключаю.
Есть вариант подсунуть статистику от аналогичной не временной таблицы, но это как то уж больно запарно.
Кстати, ORACLE, в данном случае, чаще всего сам создает временную таблицу, ну или ему можно подсказать хинтом /*+ materialize */ и преимущество использования WITH будет очевидно.