Уже неоднократно обсуждали что правила в описании чата трудно воспринимаются, надо по-человечески написать

Вакансии строго -> вот это непонятно что

ничо, будем страдать

=)

привет всем.

есть такая задача.
если кратко то это поиск крос курсов валют.

есть массив валют

array(eur,usd,chn,rur,cad,gbh,nzd,chn,и так далее)
все эти данные находятся в базе данных,в таблице.
почти все эти пары торгуются между собой
например
eur/usd=1.12
usd/chn=110

цель перебрать массив и найти арбитраж.

1.взять например одну любую валюту. рандомную, потом взять вторую,и взять цену первой валюты с базы данных. например вышло так eur/usd 1.12

2. берём ту вторую валюту. берём какую нибудь третью,и берём цену той второй валюты
3. повторяем также как и в пред. разы.
4. последняя валюта должна быть равна первой. т.е eur. т.е надо найти любую пару где будет евро

как это перебрать?

Никто в турцию не собирается в ближайшие дни? =)

доброго дня. подскажите, где вакансию опубликовать?

благодарю

изменил =)

Привет. В Базе есть 100к записей
Есть уникальный ключ типа ip
Как мне быстро проверить есть ли он в БД?

Просто я думаю стандартным методом будет медленно

p.s чистая пыха+mysql

построить индекс по этому полю

можно подробнее что нагуглить
пока не совсем понимаю

"mysql зачем нужны индексы"

Спасибо

о https://habr.com/ru/company/funcorp/blog/545350/

Самим наличием интерфейса вы подразумеваете, что у него возможны несколько реализаций. Обычно если вы где-то видите TranslatorInterface, то поблизости есть реализация вида Translator implements TranslatorInterface. Здесь я сразу задумываюсь: что такого уникального в этом Translator, что он получил эксклюзивное право называться Translator? Любая другая реализация потребует поясняющего наименования, типа XmlTranslator или CachedTranslator, но именно эта реализация почему-то считается реализацией «по умолчанию», что вытекает из её приоритетного имени Translator — без дополнительных ремарок.Плохо ли это? Я считаю, что да. Такой подход сбивает людей с толку: они не понимают, должны ли они требовать на входе тип TranslatorInterface или просто  Translator? Писать код иногда с учётом интерфейса, а иногда реализации?

Конкретно вот эта часть статьи - какое-то словоблудие и демагогия

Я работал и с одной системой именований и с другой и в целом субъективно более удобно когда интерфейс имеет суффикс Interface

Ну я вот прям поддерживаю, что суффикс Interface провоцирует создавать реализацию без именования реализации
Те если у вас четко XmlTranslator и TranslatorInerface то в целом пофиг (за исключением оверхеда буковок), но разработчик в большинстве своем ныне "не очень" и стопудово для TranslatorInerface сделает класс Translator