Можете посоветовать как к этому подойти? Может есть какие-то источники, которые я не смогла найти, где говорится, как это делать? Мне кажется, что это возможно, потому что Авито был до того как появился реакт, как-то же это сделалиПочти любой современный сайт состоит из 2 основных частей: Фронтэнда и бэкэнда. Фронт - то что отображается в окне браузера, бэк - серверная часть, отвечающая за чтение, изменение и сохранение данных, которые можно вывести для клиента в любой удобной форме. По этому для реализации вашего проекта понадобятся знания не только верстки и js, нужно будет и разобраться с серверной частью, которая обычно состоит из движка на каком-то языке, подходящем для веб разработки (PHP, Pyton, Java, JS...) и базы данных, где будут храниться собственно данные о пользователях, объявлениях, просмотрах и т.д.
Может есть какие-то источники, которые я не смогла найти, где говорится, как это делать?А искали?
Проблема в основном в том что нейронка ошибается,.так как если механик станет напротив номера она напишет дубль этого автомобиля.Я так понимаю проблема в том что проходящий механик заставляет нейронку еще раз считывать номер машины и заново считать интервал простоя авто в боксе?
Какие способы есть быстро и эффективно проштрудировать .php файлы на наличии в нем кириллицы и задать блокам-родителям уникальные идентификаторы(к примеру data-translate="a += 1")Думаю что вариант с маркировкой блоков заведомо кривой, я бы искал регуляркой по русским символам и в местах текста менял бы на что-то типа
<?=_t('найденный текст');?>, ну и 'найденный текст' использовал бы в качестве ключа к переводу фразы в структуре переводов. И с бэкенда уже все приходило бы в нужном языке (что позволяет вообще практически не менять фронт). Это исходя из того что сайт самописный, на какой-нибудь ларе есть куча готовых мультиязычных решений.
Сможет ли, будет ли индексировать один и тот же урл в разных версиях?Самостоятельно - нет, через сайтмап - да, но криво.
Несколько лет писал его под Windows (C# в MS Visual Studio) ... На что посоветуете перейти? Надежд на перенос кодовой базы не питаю, смирился с тем, что придется писать с нуля.а в чем проблема?
Но тут возникает проблема в формировании prepared statements в PHP (PDO).А в чем проблема?
$sql = 'SELECT *
FROM articles
WHERE name LIKE ?
AND name LIKE ?';
$prep = $dbh->prepare($sql);
$ret = $prep->execute(['%' . 'опух' . '%', '%' . 'поч' . '%']);И вот здесь основные сомнения: сделать выборку из 15 000 строк быстрее, чем из 60 000 (и будет больше) с WHERE city='spb'. На старте хотелось бы сделать правильно, чтобы при последующем развитии не упереться и переписываться все заново.Современные бд вообще с такими объемами смешными справляются достаточно легко, скорость может проседать в районе миллиона записей (утрированно, но где-то близко к истине), и там уже надо думать как это хитро индексировать/шардировать или тюнить железо/софт (естественно и тестовая машина должна быть какой-то адекватной конфигурации). По этому такая экономия на спичках по итогу выйдет боком. Собственно вам ничего особенно не стоит создать фейкером 15/60К записей со связями и прогнать эксплэйн на запрос, посмотреть чего в индексах не хватает, как быстро идет выборка... И WHERE city='spb' скорее всего вам аукнется, нужно связывать со справочной таблицей городов и соединять по айди-сити_айди, или через пивот, если у товара может быть больше одного города.
Ребят вы знаете, в чем проблема, и куда копать....Нет конечно... Берете код, бьете на блоки, расставляете метки времени, отчет по затраченному времени пишете в лог. Проблемные места смотрите и решаете можете ли уменьшить время исполнения. Вангую что самые тормоза у вас будут на выборке из бд или на запросах к апи. В случае бд - вывести запрос и сделать explain. По результату уже можно будет что-то советовать. В случае тормозов с апи - тут уже ничего в плане оптимизации сильно не придумаешь, но в любом случае задачи лучше будет скинуть в очередь и уже оттуда они будут выполняться, пока не закончится список. Кроме того, выборка по одной записи из бд в цикле - классическая ошибка, нужно объединить все запросы в один через join или in(), а дальше работать с полученным массивом.
ini_set('error_reporting',E_ALL); ini_set('display_errors', 1);