Делать 4 таблицы (коммент запроса, похожие фильмы запроса, коммент ответа, фильмы ответа) не очень хочется во нескольким причинам:
слишком много запросов в БД будет на получение списка запросов на просмотр (запрос, фильмы, кто, что советует)
слишком много лишних телодвижений будет и при ответеЧто значит слишком много? По сравнению с чем?
Вообще, 4 таблицы — это будет нормализированный способ хранения ваших данных. Можно и денормализировать, но это ухудшит расширяемость и возможности по манипуляци данными средствами SQL. Иногда денормализация приемлема, просто нужно в полной мере осознавать, какими будут последствия.
Например, можно сделать две таблицы: Comments и CommentMovies. В Comments добавить поле IsQuestion, в котором хранить TRUE, если это вопрос и FALSE, если это ответ. CommentMovies будет хранить фильмы как для вопросов, так и для ответов.
Минусом такого подхода будут проблемы функциональной расширяемости. То есть, если вы захотите добавить в таблицу Comments поле, присущее только вопросам, то у вас будет, по сути, три пути:
1) Рефакторинг структуры: разделение на ваши исходные 4 таблицы. Это трудозатратно;
2) Добавление ещё одной таблицы: QuestionCommentFields. Структура получается корявой;
3) Создание поля, которое будет хранить значения только для одного типа строк. Это уже денормализация.
Можно фильмы хранить в виде строки в основной таблице, перечисленными через запятую. Это денормализация, она упростит структуру, но усложнит и замедлит изменение и поиск данных.
В общем, выделите для себя какие-то приоритеты и путеводные камни. Будет ли структура часто меняться в будущем, важна ли простота поддержки? Важна ли скорость выполнения запросов, важна ли возможность менять данные напрямую SQL'ем? И т.п.
SELECT Id, translate(Value), translate(Value2) ...
class Leaf {} // лист
class Thorn {} // шип (т.к. тычинка вроде как у всех цветковых есть)
class Flower // цветок
{
Leaf[] leaves;
}
interface Thorny // с шипами
{
Thorn[] thorns;
}
class LilyPetal {} // лепесток лилии
interface CuteThing {} // красивая фигня
// лилия — шипастый цветок, да и к тому же, красивая фигня
class Lily : Flower, Thorny, CuteThing
{
LilyPetal[] petals;
}
class Apartment // квартира
{
CuteThing[] things;
}
«как назвать интерфейс, который позволит Testing_Database_Cache_Cookies использовать посторонний класс Fuston_Http_Response_Cookie как свой собственный Testing_Database_Cache_Cookies_Cookie?»… то непонятно, зачем это вообще нужно. Особенно учитывая, что зачастую это невозможно.