ThunderCat

confirm()

Вариантов много
1) Конвертер - пишется на одном языке, затем скармливается конвертеру, и получаем код на другом языке. Обычно работает криво, не всегда как задумывалось, а иногда тупо не работает. Причина - все языки сильно разные, и не все можно однозначно перевести друг в друга без потери функционала.
2) Микросервисы и отдельные программы. В принципе это немного разные подходы, но суть одна - каждый язык компилится в бинари, а между собой общаются через апи или тупо из командной строки друг друга дергают, как вариант - через третий связующий сервис.
3) Библиотеки. Пишем либу на С, подключаем к пыху - вуаля, у нас получился Фалкон!

Вроде есть еще какая-то экзотика, но склероз, склероз... а, вроде что-то типа распределенной программной среды от МС, оно уже сдохло, но существовало некоторое время как "очень перспективная технология", но не срослось... Думаю кто-то из олдфагов даже вспомнит точное наименование...

Возможно будет проще если сделать 2 или 3 базовых параметра, которые точно исключат похожесть (ну например цвет кожи, разрез глаз, форма подбородка и т.п.), и/или например добавить поле со сниженным качеством кодирования до 64-32, дабы уменьшить выборку, и делать уже на основе остатка выборки перебор.

С учетом прослойки в виде какого-то серверного языка, коннекта и передачи параметров запроса - один запрос будет быстрее, не сильно, но да, быстрее.

SELECT * 
FROM mydata 
WHERE id < '127' 
AND mytarget = (
   SELECT mytarget 
   FROM mydata 
   WHERE id = '127' 
   ORDER BY id DESC 
   LIMIT 1
) 
ORDER BY id DESC 
LIMIT 1

Задача простая, развернуть картинку.

Для чего? Что с ней дальше предполагается делать?

К примеру, пользователь загрузил картинку которая повернута в любую из сторон

На сервер? В инпут? Куда?

Когда загружаю картинки, (куда?) большая половина картинок не имеют тех данных что мне нужно (ориентация).

Логично, не все устройства их пишут, а при конвертации и пережатии чаще всего ексиф трется для сокращения размера.

Либа сама уже может развернуть картинку как нужно. Но и тут я не пойму как и что куда нужно правильно передать, что бы она развернула как нужно?

читать доку?

https://www.google.ru/search?q=folder+compare+tool
Лично я таких не видел, но это не значит что их нет...

во первых картинка тянется с другого домена по http (и не факт что он поддерживает https), соответственно хром не тянет ее так как секюрити,
во вторых - дебилизм тянуть картинки для оформления с другого домена,
и в третьих можно использовать беспротокольный урл( //domain.name...), по умолчанию будет использоваться текущий протокол.

Клиент не всегда имеет подключение к сети, поэтому необходимо работоспособность в offline режиме.

Идея (бесплатно):
Раздаете убогим файл хтмл, в котором будет:
1) прям хтмл форма, которую ваши чукотские оленеводы заполняют, и по кнопочке "сохранить" вся ваша форма оформляется в жсон и просит сохранить файлик локально (через блоб и вот это все). По вкусу - перенести содержимое файла на оленью шкуру/флешку, отправить голубиной почтой/оленями/с ямщиками до вашего офиса. Еще и получите данные в удобной для обработки форме.
2) Ссылка на скрипт с вашего сайта/домена, который при загрузке подменит функционал вышеприведенной формы на отсылку данных овер богомерзкий хттп(с). В случае отсутствия этих ваших инернектов скрипт тупо не загрузится и все пойдет по бороде первому сценарию.

Пользуйтесь на здоровье.

скорее всего имелось в виду именно flush(), а не ob_flush(), но с 2012 года вся эта тема не работает.

XPath("//text/javascript")

у вас как минимум 2 раза будут находиться по прегматчу строки, в вашем случае "origin":"MOW","destination":"AER", по этому дубли будут скорее всего всегда.

По порядку:

Браузер выдает следующую ошибку:

Во первых не браузер, а сервер, а браузер ее только отображает. Во вторых это уведомление и предупреждение, а не ошибка.
Далее, если ваш $view->assign('persons', $data); работает верно - значит в индексе ДО этого места в дата ничего нет. Что легко проверить с помощью вар_дамп. И если там не пусто - что-то в вашем вью работает криво, или не так как вы предполагаете, читайте документацию к данному методу.

джоин выданные книжки с книжками и с авторами и сум(авторс.ид) груп бай авторс.ид

запихнуть в БД, но при этом сначала сверить.

Что и с чем?

При небольших данных, я читаю всю нужную мне таблицу и работаю уже с ней как с массивом. И потом проверяю.

Наихудший из возможных вариантов, конечно же, не зависимо от того что вы там сверяете - это полный ахтунг.

Но проблема появляется, когда такая таблица разрастается и одновременно данных много приходит.

Логично и ожидаемо

Делать каждый раз проверку, напрямую в БД, мне кажется, что тоже не особо рационально,

Сильно зависит от проверки, как и от задачи в целом, которую вы так и не озвучили, что вы там проверяете...

Как решают задачи подобные задачи?

По разному, немного конкретики сильно поможет подобрать верный алгоритм работы.

Вопрос: Почему бы не использовать

Во первых, так вы не будете знать в чем причина - в логине или в пароле, или в обоих полях. Во вторых, это МОЖЕТ работать с ключами, но с паролями так не работает, там другой алгоритм сверки, и желательно не плодить сущности и создавать максимально близкие по реализации алгоритмы в похожих местах.