типа с использованием convert castлюбой каст это костыль, сильно снижающий производительность. Ты же понимаешь, что все значения в таблице для кастовых операций нужно привести в один вид, то есть каст будет на все данные сразу, иначе сравнивать преобразованные данные с непреобразованными не получится. Как разовый запрос с целью что-то быстренько под себя получить конечно можно, но на крупном проекте с миллионами записей будет очень больно...
там далеко даже нет таких выборокТам нет таких выборок сейчас, не факт что завтра тебе не понадобится выбрать какие-то статистические данные по сегментам, даже тупо разбить на календарные месяцы будет уже неслабым геморроем...
SELECT DATEDIFF(date, CURDATE()) days_until
FROM dates_table
WHERE date >= CURDATE()
AND DAY(date) = 13
AND WEEKDAY(date) = 4
ORDER BY date
LIMIT 1;
Что то такое в таймстампах бигинт? средствами sql не подскажу,Уже хорошо
нужно получить дату текущую например раз работает с московской, то московскуюДопустим...
из этой даты получить 4 метки,Какие? Почему 4?
вот я работаю постоянно с датами через биг инт, и все даты - временные метки timestamp - как думаешь исходя из твоего опыта - плохой ли это подход ?Средствами sql, вытащи мне все даты, которые будут через 3 недели, с понедельника по пятницу, время у которых в диапазоне от 14 до 18 часов (банальная запись к врачу допустим). С полями хранящимися в bigint.
В комментарии автоматом прилетает user_id,Он не "прилетает автоматом", он получается из связи, то есть читается из соответствующей таблицы, согласно установленных связей.
а могу я его сам устанавливать?Короткий ответ - нет. Но вы можете обработать полученный результат и заменить в нем все что угодно на что угодно. Короче, троллейбус из буханки.жпег
Хочу использовать для вывода переменных во время тестирования скриптов, т.е. в процессе отладки.Если смысл сделать обертку поверх стандартных принт_р/вардамп, то проще всего расположить эту функцию в начале единой точки входа (если таковая есть), или подключать файл с необходимыми функциями через include/require. В большинстве случаев для такой работы есть более эффективные инструменты, такие как логгеры или дебаг процессоры (например Xdebug или ларовеловский логгер). Как вариант, можно использовать статические методы отдельного класса, заточенного под дебаг.
В вашем ответе вы зачем-то начали давать оценку процедуре действий. У меня вопрос на этом построен? Я просил дать оценку своей логике и процедуре?Э, да. Вот же:
Какой метод локализации(перевода) сайта более эффектинвый..? ... Изначально, задумка следующая:что говорит о том что идея есть, но она сырая, предполагает что-то конечное как решение.
Кто работал в данном направлении, какие есть эффективные и +- не дорогие(лучше бесплатные) сервисы которые интегрируются в Python, PHP или работают по APIЯ работал, МНОГО, практически все мои проекты в той или иной степени мультиязычные. Я знаю как это делать правильно, и использовал за 15 лет разные сервисы. Не хотите советов или не нравится ответ - нет проблем, не пользуйтесь. Достаточно написать "спасибо, не подходит".
Второе - есть уникальные тексты с описанием авто из бд - в день публикуется порядка 30 тыс. автомобилейОни лежат в бд. Ничего не мешает написать обработчик на 20 строк который будет постепенно переводить легаси записи в нормальный перевод. Тем что они у вас не лежат в хтмльках (как иногда случалось у меня) радоваться и пользоваться надо, а не выставлять это как проблему.
Переписывать локализацию - долго, очень долго.Это все равно будет долго и геморно, ваш подход никак не решает собственно задачи мультиязычности, например тот же поиск на втором языке тупо не будет работать.
Один обработчик AJAX только около 18к строк кодаСочувствую. То что у вас там каша из кода и представлений конечно сильно добавляет гемора, но не отменяет необходимости рефакторинга.
Какими способами или ПО можно оперативно пройтись по .php файлом и найти все элементы веб-странице, которые содержат кириллицу И выполнить их идентификацию путем добавления data-translate="a += 1"Тем же пхп или питоном, + регулярками. Или, что более адекватно, DomDocument + xpath. Опять же - мое мнение, вы делаете похожую работу, но усложняете ее в разы с вашим json файлом. Сделайте список фраз, пусть даже в том же json, и переводы к ним в 1 файле переводов, тогда, как я писал, сами фразы и будут ключами для перевода, а не эти вот непонятные метки в разметке. И сделать это регулярками сильно проще, и функционал понятнее.
Вопрос перечитайте внимательно. + update к нему.Ответ перечитайте внимательно. Вы принципиально иначе работаете. Вы берете каждый раз данные и прогоняете через переводчик, вместо перевода контента в момент создания. Ну или не умеете описывать задачу, не вижу в вашем описании где вы сохраняете на сервере перевод, вижу что вы гоняете контент на сервер, там дергаете транслятор, а результат обратно отправляете на клиент.
Первый вопрос заключен в выборе обработчика перевода текста.Для того решения которое я описал, скорость вообще не особо важна, так как перевод будет происходить в момент добавления 1 раз, кроме того - чем вы смотрели, я написал что современные нейронки делают это недорого и качественно. Их и рекомендую.
Второй - про идентификацию элементов.Надо искать не элементы, а текст. Ищется регуляркой, включающей все русские символы. Задавать блокам родителям идентификаторы НЕ НУЖНО. Нужно 1) перевести текст в шаблонах, 2) перевести текст в динамически строящихся элементах, 3) С сервера передавать готовые переведенные текста.
У меня сейчас это такВы мешаете сущности в одну кучу, от этого у вас лажа. Учитесь отделять сущности, создавать зависимости и работать с реляционными базами данных согласно 3 нормальной формы, станет сильно проще.
оно смотрит если есть этот номер в статусе completedАга, значит если статус completed, мы его затираем и больше никак не можем посмотреть когда была машина в прошлый раз... Гениально...
И это уже будет дубль той же машиныЭто самое тупое заявление из всего вышенаписанного, так как для системы никакого дубля нет, есть 2 машины AA1234AC и AA1234AO. Проблема не в хранении или дублировании, проблема в шумах распознавания (что и надо было объяснить).
Раз проект новый, то я бы рекомендовал брать Postgresql.Вот кстати - зачем? Что постгрес даст в противовес мускулю конкретно в этой задаче, да и в целом - "в чем сила, брат"? Я работал как с постгресом, так и с мускулем, сказать что я как-то заметил разницу в производительности на больших объемах - ну, нет. Больше похоже на карго культ, навеяный пиаром... Или есть что-то "сокрытое от глаз"?