Я использую MySQL в нем вроде нет ROW_NUMBER
Допустим один документ с подписью, а другой без. И надо признать их одинаковыми и не добавлять копию в базу.
а как при не 100% точности подходит сравнение хэшей?
Думали еще из файлов выдирать контент, закидывать его в elasticsearch и потом для новых файлов по нему делать поиск.В описанных мной вариантах - в первом Вы вообще ничего не выдерете (если не прикрутите безошибочный OCR, которого не существует), во втором Вы получите малоосмысленный набор символов, пригодный только как упражнение на дешифровку многозначного подстановочного шифра (и его тоже проще распознать. чем дешифровать).
с точностью совпадения, допустим в 99%. Поэтому по хэшам не подходит.Вот как раз при высокой, но не 100% точности, сравнение хэшей подходит как нельзя лучше.
мне хотя бы просто осмыслить, как создать эти два последних столбца
Забавно такое слышать... кто, кроме Вас. может сказать правильно или нет...
Не, запрос работает, само собой, и что-то даёт: https://dbfiddle.uk/?rdbms=oracle_18&fiddle=dfd7e7...
Давайте по шагам. Сначала свяжем. Задача какая?
Значит, первым шагом должно быть получение всех комбинаций item / zone из rpm_zone_future_retail, вне зависимости от того, есть они там где-то или нет.
Вторым шагом будет выбор тех из них, что отсутствуют в rpm_future_retail. И тут мы упираемся в то, что в таблице rpm_future_retail нет поля zone... и соответственно вопрос - где его брать-то? из зависимости (rpm_future_retail + rpm_zone_location)?
https://dbfiddle.uk/?rdbms=oracle_18&fiddle=c7a4f6...