Если мне память не изменяет, то указываешь их также, как и при id полях. Только лучше сделать тогда индекс для колонки Second_name в таблице second_name, это позволит ускорить запрос.
Так для того, чтобы сделать cross-table update, вам нужно:
1. выбрать N таблиц, с которыми будете взаимодействовать,
2. провязать их через необходимые общие поля в таблицах(join), иначе как вы поймете, что именно эта строка во внешней таблице, должна подойти другой строке, в которой происходит обновление.
3. определяете операции присвоения значений
4. А дальше уже фильтруете по необходимым условиях.
Прошу прощения, за последний источник, просто сам им пользуюсь время от времени и много чего там находил.
Если брать книги, то я обычно смотрю на амазоне популярные книги и дополнительные рекомендации к ним. Как правило, в 80% случаев эти книги есть в свободном доступе где-то в сети. Мне было достаточно просто погуглить.
RidgeA, почему на go? Я на нем сам еще не писал, поэтому не могу сказать ничего в частности по нему. Однако, я погуглил быстренько про него. Его хвалят, что он в разы быстрее и эффективнее по использованию ресурсов, чем питон. Однако, в данной ситуации, скорость времени разработки тоже важный фактор, отсюда следующий вопрос: на нем дольше писать чем на питоне?
Валидация пока будет не сложная, потому что она может изменяться со временем. Суть валидации будет заключаться в проверке клиента по заголовкам, в основном, и частично по телу запроса. И еще, моя ошибка, что сразу не сказал. Перед валидирующим сервисом будет стоят nginx, который будем заниматься предпроверкой запроса и затем проксировать запрос в валидирующий сервис, либо в другое место, что бы разгрузить инфраструктуру за ним, и сервис в том числе. Дальше, также забыл сказать, валидирующий сервис также будет собирать и обрабатывать некую статистика по клиентам и хранить ее в своей базе.
По поводу количества запросов, точно сказать не могу, но ожидаемое количество может достигнуть 20к в минуту.
В теории все так и выглядит)) Однако, по факту, это будет бутылочное горлышко, и хотелось бы увидеть более описательный вариант. К примеру, на каком языке лучше реализовывать, чтобы был запас скорость, но при этом, по сложности и времени, затраченного на разработку, было
быстро в реализации, так как возможно обьем трафика выростет и придеться думать, как его переписывать. Дальше, использовать какой-то фреймворк или вообще отказаться от него в пользу минимизации всего и всех и т.д. Может есть какое-то готовое решение в виде стека технологий, над которым стоит подумать. Надеюсь я правильно изъяснился, что бы вы поняли суть вопроса.
Спасибо за подсказку. Действительно, то что плагин отрендерил находится в двух местах. В первом случае, div отобразился, там где надо(внутри wpbody_content), а во втором отобразился в просто body, перед всеми инклудами линков, скриптов и всем прочим. Подскажите функцию, котоую нужно вызвать перед рендером?
