Надеюсь эту картинку вы знаете?



Допустим, таблица A это SELECT * FROM games, а таблица B это SELECT * FROM uploaded_games WHERE user_id = ?.

Т.е. вам нужно из таблицы A вычесть таблицу B (в терминах теории множеств). На картинке это левый столбец, второй сверху.

SELECT *
FROM games as A
LEFT JOIN uploaded_games as B ON (A.game_id = B.game_id)
WHERE B.game_id is NULL AND B.user_id = ?

Можно записать более наглядно, но, скорее всего, MySQL его не соптимизирует эффективно

SELECT *
FROM games
WHERE game_id NOT IN (
  SELECT game_id FROM uploaded_games WHERE user_id = ?
)

XSLT советую. Для него можно XML-ку собрать каким нить SimpleXML — очень удобно. Каждый модуль проекта может в один и тот же объект SimpleXML вставлять свои данные а потом XSLT уже выбирает то, что ему нужно.

Из плюсов — хорошо переносится между языками (если вдруг понадобится), можно с помощью тех — же XSLT попробовать реализовать REST API. Да просто довольно правильный стиль навязывает при создании шаблонов. Опять же, для NGINX есть модули для XSL трансформации внутри него (хотя смысла делать шаблонизацию внутри легкого асинхронного веб-сервера я лично не вижу)

Если умудриться распарсенные шаблоны каким-то образом сохранять в памяти между запросами (на PHP трудно реализуемо пожалуй) то вообще летать будет.

При установке с нуля ставлю кодеки, архиваторы, Chrome, флеш, скайп.

Но стараюсь по-возможности сохранить список софта с уже настроенного компа dpkg --get-selections > software_list и применить его к новой установке dpkg --set-selections < software_list ; apt-get dselect-upgrade.

У меня половина опыта работы — именно написание пауков и веб-парсеров.
Писал их и на PHP + CURL, потом на голом питоне + треды.
Потом узнал о Scrapy (асинхронный фреймворк для граббинга сайтов на Python) и на нём штук 5 независимых проектов реализовал, в том числе один, где нужно аггрегировать и периодически обновлять информацию с 20 различных форумов. Основная его проблема — он асинхронный, но однопоточный. Так что больше одного ядра им не нагрузить и долгий запрос к БД не сделать. А так очень хороший фреймворк.
Потом несколько пауков делал на Python с помощью Celery.
А совсем недавно переписал довольно сильно нагруженного паука (50-70Мбит/с через списки прокси) с Python + Celery на Erlang и понял, что это ОНО! Мало того, что стал работать в 2-3 раза быстрее, но понял, что для этой задачи что-то более подходящее сложно придумать.
Поясню — у паука на Erlang можно без остановки процесса, например, изменить число потоков, обновить код, перезагрузить конфиги. Можно на ходу отпрофилировать код чтобы узнать, почему скорость упала или что так нагружает CPU. Можно совмещать зеленые потоки, асинхронную работу с сетью и долгие запросы к БД. И всё это фактически из коробки. В конце концов, код получается более логичный.