Shedal

Делать 4 таблицы (коммент запроса, похожие фильмы запроса, коммент ответа, фильмы ответа) не очень хочется во нескольким причинам:
слишком много запросов в БД будет на получение списка запросов на просмотр (запрос, фильмы, кто, что советует)
слишком много лишних телодвижений будет и при ответе

Что значит слишком много? По сравнению с чем?

Вообще, 4 таблицы — это будет нормализированный способ хранения ваших данных. Можно и денормализировать, но это ухудшит расширяемость и возможности по манипуляци данными средствами SQL. Иногда денормализация приемлема, просто нужно в полной мере осознавать, какими будут последствия.

Например, можно сделать две таблицы: Comments и CommentMovies. В Comments добавить поле IsQuestion, в котором хранить TRUE, если это вопрос и FALSE, если это ответ. CommentMovies будет хранить фильмы как для вопросов, так и для ответов.
Минусом такого подхода будут проблемы функциональной расширяемости. То есть, если вы захотите добавить в таблицу Comments поле, присущее только вопросам, то у вас будет, по сути, три пути:
1) Рефакторинг структуры: разделение на ваши исходные 4 таблицы. Это трудозатратно;
2) Добавление ещё одной таблицы: QuestionCommentFields. Структура получается корявой;
3) Создание поля, которое будет хранить значения только для одного типа строк. Это уже денормализация.

Можно фильмы хранить в виде строки в основной таблице, перечисленными через запятую. Это денормализация, она упростит структуру, но усложнит и замедлит изменение и поиск данных.

В общем, выделите для себя какие-то приоритеты и путеводные камни. Будет ли структура часто меняться в будущем, важна ли простота поддержки? Важна ли скорость выполнения запросов, важна ли возможность менять данные напрямую SQL'ем? И т.п.

Я себе так представляю, что те, кто не хочет платить за вашу CMS, всё равно за неё платить не будут. Или взломают, или найдут другую, бесплатную систему, благо, их сейчас очень много.

Если же ваша система будет предоставлять какие-то конкурентные преимущества (функциональность, быстродействие, дизайн, etc.), то компании, которые захотят платить, даже не станут искать способа её взломать.
На самом деле, есть ведь системы с открытым исходным кодом, которые разрешается использовать бесплатно в некоммерческих целях, в противном случае нужно платить. И люди платят — по одной из следующих причин:
— большие компании чувствуют себя более уверенно, когда используют платный софт. В этом случае у разработчика, вроде как, есть какие-то обязательства перед клиентами;
— платный саппорт, по той же причине;
— просто хочется поддержать хороший проект.

Как вариант, можно создать таблицу translations (text, culture, translation).

Определить функцию translate(text, culture), которая будет возвращать или перевод, если он есть, или изначальную строку, если перевода нет.
Использовать её можно будет с любой таблицей:

SELECT Id, translate(Value), translate(Value2) ...

Конечно, для разных ситуаций подходят разные решения. Например, из вашего описания непонятно, нужно ли вам переводит данные из одной или многих таблиц, могут ли строки текста переводиться по-разному в зависимости от контекста, и т.д.

Думаю, изобрести несколько велосипедов для опыта не помешает :) В конце-концов, тогда начинаешь лучше понимать, как примерно работают уже готовые решения, которые используешь.
А как научить использовать готовое — сложный вопрос. Главное здесь — подход мышления. Когда начинаешь что-то делать, сначала поищи, не реализовал ли этого кто-то для тебя? Ведь 99%, что реализовал :)

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?»

… то непонятно, зачем это вообще нужно. Особенно учитывая, что зачастую это невозможно.
Название класса должно кратко описывать сущность, а не говорить об особенностях внутреннего устройства.