Если у вас есть нерекурсивный нисходящий (Forum -> Thread -> Postings) поиск ваших данных для наиболее распространенного варианта использования, тогда эта структура таблицы будет хорошим началом, потому что это приведет в основном к WHERE ParentId = @SomeId запросов.
Если вы захотите вычислить такие вещи, как «Сколько сообщений существует в этом форуме / теме?», Вы легко попадете в ситуацию, когда вы не сможете определить, какие идентификаторы вложены в какие другие идентификаторы (т.е. детские отношения отсутствуют).
Вы могли бы объяснить это путем избыточного сохранения ThreadId и ForumId в каждой публикации. Тогда вы сможете спросить SELECT COUNT(*) FROM Postings WHERE ThreadId = @SomeId.
Эти идентификаторы вряд ли когда-либо изменятся для данной публикации, поэтому избыточность не сразу создаст аномалии вставки / обновления, но у вас должна быть процедура для обновления всех связанных публикаций с правильными идентификаторами в случае, если вы решите переместить вещи вокруг.
Чтобы получить более продвинутые способы хранения иерархических данных в СУБД, вы можете посмотреть ответы на этот вопрос (это мой собственный вариант, не предусматривающий фишинга): «Что является наиболее эффективным / элегантным?» способ разбить плоский стол на дерево? "