CAH4A

Преждевременная оптимизация приносит больше вреда, чем пользы.

Ответ теоретический, вне контекста 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. То, что вы предлагаете — светлая инженерная мысль, удачи вам.

Мне кажется, есть такое заблуждение, что выкладывание проекта в открытый доступ привлечет к нему активное внимание, в том числе и нежелательную критику. В психологии даже термин есть для этого: spotlight effect.

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

— Исправьте откровенные косяки, если такие имеются.
— Сделайте небольшой файл README с описанием возможностей и правильного способа установки
— Выложите на github. Публикация на github не накладывает серьезных моральных обязательств :)
— Если стыдно сообщать о проекте всем, расскажите только своим друзьям. Вдруг им понадобится и понравится.

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

Из быстро заметных позитивных моментов. Выкладывание проекта в открытый доступ, скорее всего, приведет к повышению уровня сознательности при добавлении нового функционала в проект, что благотворно скажется на общем качестве кода. Все-таки мысль о том, что кто-то может сделать code review, даже потенциально, она дисциплинирует.

Сам по себе ORM, именно как maaping, в крупных проектах нужен как раз очень сильно. Опишу здесь свой опыт. Если понравится кому, может и статью потом.

Итак.
Представьте себе — у меня есть очень крупная система, и есть в ней таблица orders, в ней скажем, 50 колонок (на самом деле у нас 150, ну да ладно. Нормализаторы, молчать! Про нормальные формы я тоже знаю). И вот надо значит вам выбрать один ордер и показать его на экране. Допустим, вы пишете селект, неважно. Дальше что делать, в промежуточном слое? Вы не же вызываете хранимую процедуру (запрос) напрямую с, скажем, JSP страницы (я надеюсь), вам все равно надо получить данные и передать их как-то.
Так что, передавать их в виде массива, ArrayList-a, ассоциативного массива имя колонки/значения? Ну так дико громоздно, неудобно, и очень легко ошибиться. А если вам надо несколько ордеров, тогда что, создавать вложенные коллекции для конвертации результатов? Неудобно же.

Потому, очевидно, нам нужен объект Order, имеющий все нужные property, и нужен код, который умеет конвертировать результаты скл запрос в эти объекты (или коллекцию этих объектов).

Далее, очевидно, что писать руками _все_ запросы трудно и нудно, легко ошибиться, т.к. в Java они будут представляться в коде в виде строк (а значит, никакой статической типизации и compile-time проверок и прочее и прочее), и их надо держать либо в Java коде (если они мелкие), либо, если побольше, выносить в отдельные XML файлы.

В общем, ORM в больших проектах нужен для упрощения рутинной части. Без него — никуда :)

Безусловно, обойтись ТОЛЬКО ORM не получится. Есть у нас масса мест, где сложная логика написана в хранимых процедурах в 500-1000 строк на PL/SQL, написанная через ORM /Java она бы занимала в 10 раз больше и работала в 2 раза медленнее (при этом, она была бы еще и менее понятная, т.к. есть такая логика, которые в терминах реляционной алгебры описывается куда проще, чем в терминах ООП :), следовательно ложится на ORM со скрипом). Сколько нибудь сложные запросы с подзапросами, юнионами, хитрыми джойнами тоже писать через чистый ORM громоздко. Оптимизировать запросы, работающими в таблицах где, хотя бы, несколько сотен миллионов записей, без доступа к планам SQL оптимизатора и статистики/средствам мониторинга уровня СУБД тоже крайне сложно. Так что без SQL тоже — никуда :)

Для начала посоветую посмотреть доклад Дмитрия Девишева (Mail.ru) с КРИ-2010. Дмитрий рассказывает о трудностях разработки игровых онлайн проектов.
Из оффлайна в онлайн (6 частей):
www.youtube.com/watch?v=KteOkdvPmdA
www.youtube.com/watch?v=_Tl1ymSmsQY
www.youtube.com/watch?v=ekmXj9L5bmo
www.youtube.com/watch?v=9mD3AmzUl4g
www.youtube.com/watch?v=wjer9nPMVYI
www.youtube.com/watch?v=04MlZt58lio

Онлайн-игры бывают разные. Слишком много их типов чтобы прямо отвечать на такой «вопрос».
Определитесь с тем, что это за игра, какого жанра, составьте минимальное ТЗ, в конце концов.

Нужно ли веб программисту веб образование?
Это каждый решает сам. Если нужны корочки то почему бы и не купить.
Если нужны знания и есть время посещать вуз, почему бы и не поучиться.
Если нужны знания и нет времени бегать в вуз, можно учиться самому и/или нанять репетитора в нужной области.
Взять хотя-бы Била Гейтса у него не было высшего образования.
Если ты профи высокого класса то твои корочки вообще не кому не нужны.
А если ты не супер-гуру, а рядовой программист, то корочки могут и пригодиться.
Если есть планы не работать на кого-то, а открыть свою контору, тогда корочки не нужны будут.
Учеба в Вузе дает связи которые очень бывают необходимы…
И так можно продолжать долго…

Вынести чтение для удаленных юзверей на slave сервер (может размещаться на той же железяке, только использовать отдельный hdd), а запись на мастер. Разделить чтение и запись можно с помощью mysql proxy forge.mysql.com/wiki/MySQL_Proxy_RW_Splitting.