kazmiruk

Я бы взял pymorphy (я даже не выбирал в принципе, так как php не приемлю, но не суть), так как phpmorphy не поддерживается больше разработчиком (последнее изменение 4 года назад) и Вы останетесь со всеми вопросами и багами один на один.
Какой инструмент имеет круче предсказатель - накатайте тестик по формированию частотных отношений лемм и натравите на хабр, к примеру. А потом смотрите на результат (думаю он не будет отличаться даже) На pymorphy это примерно 20 строк кода. На phpmorphy думаю не многим больше. Результат работы pymorphy по определению части речи и выдергивания лемм меня более чем удовлетворил.
По скорости - разработчик pymorphy заявляет, что одной из задач для него была оптимизация, поэтому есть шанс, что работать будет быстрее.

SELECT * FROM employee WHERE employeeID NOT IN (SELECT id_employee FROM employee_to_training WHERE id_training = < id >)

printf("%06d", 000000 + 000001);
или если нужно в переменную, то
$x = sprintf("%06d", 000000 + 000001);

Метрики для определения формата не всегда однозначны и трудно формализуются. Создать какие-то приближенные методы возможно, но они будут работать не со 100% результатом (хотя, возможно, и близким к ним). Работал над чем-то подобным для обработки наборов изображений поступающих роботу и ничего адекватного для С++, python, C# не нашел. По пхп не точно, но предполагаю, что ситуация аналогичная. Ну и подобную задачу решать на пхп не самый лучший вариант, так как для распознавания в любом случае потребуется разбор изображения, получение производных и т. п. в чем пхп явно не лучший игрок.

SELECT *
FROM Peoples
INNER JOIN peoples_to_region
ON Peoples_to_region.people_id = Peoples.id AND Peoples_to_region.region_id IN ({region_list})
INNER JOIN Peoples_to_metros.people_id = Peoples.id AND Peoples_to_metros.metro_id IN ({metro_list})

Ну и peoples - "народы" переводится, а не "люди"

Можете использовать fastcgi_finish_request, если на сервере у вас стоит php-fpm. Его суть в том, что скрипт висит еще некоторое время (пока не выполнятся все операции) после ответа клиенту. Но это неправильный путь. Вреное решение будет примерно такое: вы присылаете аякс, валидируете данные, добавляете в очередь сообщений (я люблю gearman, но вы можете использовать любую другую) запись, что надо отправить письмо. Как только в очередь добавляется запись обработчик хватает его и отправляет.

Вы изначально неверно поняли картинку, посмотрите внимательно какие технологии используются на фронтэнде (HTML, CSS, JS). Обычно делается так:
бекэнд - любой язык, REST
фронтэнд - nginx отдает index.html (условно говоря на любой запрос) + стили + js (много кода на js. Фактически вся логика сайта написана на js). JS код уже смотрит на текущий адрес страницы, производит роутинг, рендерит layout (пока ни одного запроса к бекэнду, кроме инициализирующего), затем по ссылке он понимает какие данные ему нужны от бекэнда (к примеру список задач на сегодня) и делает асинхронный запрос (из js'а. Это может быть несколько запросов к разным частям апи). Получив ответ на этот запрос (в виде json) js разбирает его и рендерит на шаблон (все это на js). Таким образом мы получаем: бекэнд не занимается рендерингом шаблонов, значительная часть логики отрисовки и роутинга находится на клиенте и он сам с ней разбирается, гибкость системы (бекэнд может использоваться для мобильных приложений, к примеру).
То, что описали Вы - трудно назвать правильной архитектурой. По сути Ваш "фронтэнд" - обычный прокси запросов, который все также генерит Html на сервере (тратит ресурсы сервера, а не клиента) + еще курлом гоняет бекэнд. Прироста производительности с такой архитектурой Вы не получите.

Стоит. Задача очень хорошо накладывается на модель асинхронных событий. Дергать сервер аяксом, чтобы проверить есть ли новые сообщения - не риал тайм, а если дергать часто (чтобы приблизиться к риал тайм), то создадите сами себе проблемы в виде ддоса запросами от клиентов.

1. Лучше сокет, так как не надо будет впустую теребить сервер каждые 3 секунды. Но надо помнить про поддержку сокета браузерами
2. Номер заявки. Применял похожу схему - относительно медленно работает передача из пхп через сокет, особенно если много данных. Достать из мускуля по PK очень дешевая операция.