Всем доброго дня.
Есть база данных почты на MySQL
Используются Prepared Statement  

Делаю запрос количества непрочитанных писем по ид адресата а ид адресата беру из другой таблицы по Имени


Вопрос: как лучше получить количество писем одним запросом как выше или двумя. Именно при использовании Prepared Statement




Прочитал где-то в нете, что подзапросы используют только новички

Заранее благодарен

Да все равно по-идее. Что там, что там база будет перебирать одинаковое количество строк. Только во втором случае придется их самому склеивать.

Немного оффтопа.
Для повышения производительности можно пренебречь нормализацией базы и добавлять к таблицам сущностей, связанных с пользователями, id пользователя и вешать на него неуникальный индекс. 
А в http-сессии хранить id пользователя (или целиком объект пользователя). И в запросы сразу добавлять id  пользователя.
Таким образом можно решить сразу 2 задачи: увеличение производительности и контроль доступа, так как запросы будут возвращать только строки для данного пользователя.

глупости все это

Тут двояко к ситуации можно относиться:
1. Некоторые стараются писать запросы так, чтобы за один запрос получить все необходимые данные
Недостаток этого метода в том, что будете повторять один и тот же подзапрос много раз во внешних(те которые содержат подзапросы) запросах.
Достоинство - меньшая нагрузка на сеть и на БД.

2. Добиться максимальной структуризации, т.е. для достижения цели использовать множество обращений к бд с помощью простых запросов.
Достоинство - запросы структурированы и используются многократно.
Недостаток - нагрузка на БД и на сеть.

в первом варианте запроса будет создаваться один объект содержащий данные типа
count-id-name

Во втором два объекта типа:
1. count-id      2.  id-name

Складывается впечатление, что второй на одну составляющую хранится больше, значит и памяти например выделится на 1/4 больше(утрирую)

Я не прав?

Простое лучше сложного. Пользуй второй. 

А уж когда потребуется производительность, тогда чеши репу над сложными вложенными запросами.

Я бы написал через JOIN

а если движок ИнноДБ?

Э-э-э... А что, join-ы уже запретили?



Не?

а что это меняет?

штука в том, что ИнноДБ движек использует для хранения записей кластеризованные по первичному ключу таблицы,
 а еще может построить хэш-индекс по первичному ключу.

Так задача то какая?
Чтобы работало быстро или чтобы было красиво?
Все же от этого зависит.