TJivichВопрос состоит в том, как эффективно построить доступ к базе данных через обьекты,
В этом фразе содержится внутреннее противоречие.

В данном случае Вам прямая дорога в lazy режим. Thread должен иметь коллекцию Messages, по умолчанию пустую, и загружаемую только тогда, когда кому-то потребуется.

TJivichА в чём противоречие???
В "эффективный доступ к БД через объекты", где под "объектами" понимается некий ORM.

Как бы это объяснить.... если Вы смотрели какую-либо литературу по RPC, наверняка видели утверждение, что хорошее приложение, если вдруг взять и заменить некоторые его объекты удаленными, имеет все шансы стать очень неэффективным. Рассматривая БД через ORM, Вы видите по сути "удаленные объекты-строки", к которым создаете локальную оболочку - и результат ровно такой же.

Скажем, рассмотрите тот же Thread. В списке сообщений как правило отображаются такие атрибуты, как "количество сообщений в топике", "время последнего сообщения", "автор последнего сообщения". Следовательно, эти атрибуты должны быть доступны. Каким образом?

Самый "объектный" вариант - считать список Messages, из которого они все легко получатся. Проблема в том, что тогда для обновления списка тем надо будет перечитать все сообщения форума, что вряд ли приемлимо. Поэтому, скрипя зубами, придется идти на компромисс - завести в Thread-е поле для количества, которое считать sql-ным count(), и кроме того метод наподобие GetLastMessage(), который ищет и считывает последнее сообщение. Это лучше? Намного. Эффективно? Да как сказать.. можно и лучше. Например, таким образом считывается текст сообщения, который может занимать многие килобайты и быть совершенно не нужен. Поэтому, продолжая оптимизацию, придется сделать что-нибудь типа GetLastMessageHeader(). Это уже не очень ложится в "чистую и красивую объектную иерархию", но что самое скверное, все равно значительно уступает по эффективности одному-единственному оптимизированному sql-запросу, который вернет строку типа "та информация, которая нужна в данном месте". Это уже не будет ни "топик", ни "сообщение", это будет непришейкобылехвост, но - самый быстрый.

TJivichНу про message это ясно, а что делать со списком Thread???
Это зависит от того, что Вы вообще делаете. Если планируется веб-интерфейс с сервером приложений, список тредов - явный кандидат на постоянное присутствие в памяти. Однако тут возникает вопрос истории (старых-старых тредов, когда кто-то вдруг возьмет и ткнет в двадцатую страницу форума).