TheHorse

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

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

number_format($number, 2, ',', ' ');

?
php.net/manual/en/function.number-format.php

Ответ теоретический, вне контекста php:

1. В общем случае, хранить все в .html — не быстрее.

1. 1 Если их мало и можно все хранить в ОП, то нет необходимости хранить кучи мелких файлов. Но сериализация нужна (на случай перезагрузки).

1. 2. Если файлов намного больше, чем можно впихнуть в ОП, то хранение всего в файлах, будет менее эффективно, чем другие методы. Дело в том, что таким файлам свойственно иметь большой процент общей информации. По сути в каждом файле .html может быть от 0% до 100% уникальной информации, для упрощения выкладки, припустим что это значение равно 50%. Тогда, вами используемые средства, делают на 50% больше операций чтения/записи на файловой системе, которая, кстати, является самым слабым звеном производительности, в большинстве случаев.

Если вы храните 50% общей информации (html-шаблоны) в ОП (что в большинстве случаев возможно), то вы на 50% снижаете нагрузку с файловой системы. Если быть точным, то не 50%, а вроде чуть больше, но это уже другой вопрос с «глубоким углублением».

Если 50% уникальной информации, сложны в построении (что маловероятно), либо строятся (вычисляются / считываются) не оптимальным образом, то стоимость их построения может быть выше, чем двукратная стоимость операций на файловой системе, и тогда ваш метод эффективней, но это только по отношению к операциям чтения.

Операция записи в вашем случае, в среднем будет иметь более 95% избыточности, в случае полной перезаписи. Этого можно избежать если в файле перезаписывать только то, что изменилось, но в общем случае, с учетом устройства файловых систем, это очень сложно с точки зрения системного и алгоритмического программирования.

Таким образом, у вас сильно увеличивается нагрузка на файловую систему, что сделает ваш сайт менее эффективным, по сравнению с разработками НИИ.

2. Рекомендую использовать БД. Каждая современная СУБД, крайне не эффективна, и делает то, что вам не нужно (и не один раз). Но чтобы сделать что-то лучше, конкретно для своего проекта, потребуется очень много времени.

3. Если стоит задача сделать безопасный, быстрый, надежный сайт то, я думаю, php, asp.net, python, ruby, node.js никоим образом не сравнятся с системным программированием на С/С++/Delphi (внезапно да, даже Делфи).

4. То, что вы предлагаете — светлая инженерная мысль, удачи вам.

Проблема в том что полиморфизм там корявый будет. Чтоб определить экзепляр какого класса нужно создавать, нужно сначала проанализировать содержимое запроса, что, по вашей конструкции, должно быть сделано в одном из классов потомков.

Классы что отвечают за обработку разных типов запросов — должны быть отделеньми, но прием и анализ, ИМХО — мультиплексор + фильтр = 1, 2 класса (которые не зависят от содержимого пакета).

Короче, MVC и прочие альтернативы — частные случаи более общей парадигмы, которую лично я называю Layers.
Не парьтесь по поводу MVC. Просто разделяйте разные слои/части приложения. Делайте независимые модули. Декомпозируйте/композируйте.

Не стоит приплетать MVC или что-то похожее лишь потому, что это круто.

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

Но с заданием вы очевидно справились. Порадовал inner join, хоть и не люблю нормализованные реляционные… Сделана защита от SQL-inject. В общем, нормально все.

Вывод: мудаки те кто вас собеседовал, инфа 99%. Но вроде еще наезд мог быть за использование чужих исходников.

Ну есть php-ext, и все-же рекомендую не использовать ничего подобного. Когда-то пробавал ExtPascal, лажа. Очень рекомендую отделить клиентскую часть от серверной, не смешивать php и javascript.

Может кто-то из собеседующих сам ничего не осилил и имел ввиду exec?

Рекомендую хранить дерево другим образом:
id…… pos
1…… '00'
2…… '01'
3…… '0000'
4…… '0001
Где pos — позиция коммента.
pos = pos(parent(last_child)) + 1 (если parent имеет childs);
pos = pos(parent) + '00'; ( в любом другом случаее).

Строка pos хранит точное положение коммента, по ней можно определить parent и всех child. А самое главное, для вывода дерева, достаточно сделать запрос:
select * from comments order by pos;
и одним циклом вывести весь результат на экран (без доп операций), указывая отступ от левого края равным длине строки pos.