Я бы даже еще уточнил, symfony2, на мой взгляд, единственный широко используемый php фреймворк, который можно безболезненно раздербанить на куски и использовать отдельно даже такие базовые компоненты как httpKernel и т.д. Правда zend2 я не смотрел…
Ни разу в жизни не встречал коммерческий веб-проект функциональность которого ограничивалась бы только тем что вы написали. Есть у меня сомнения по поводу того, что 80% веб-приложений реализуют только голый crud и больше ничего.
Любая нормализованная схема будет содержать кучу связей если предметная область чуть чуть более чем тривиальна. И не важно, в каких терминах мы ее проектируем, документами или реляционными таблицами.
NoSQL поощряет денормализацию, и это кстати один из минусов, т.к. делаться она должна очень аккуратно, что не всегда происходит в реальности.
Мм… не совсем верно, конечно, гибкость в настройке требует очень глубокой нормализации, например для того, чтобы создавать новые типы данных ручками, но при эксплуатации обычно используется статичная реляционная модель. Никаких eav и прочих извращений, которые всем своим видом намекают на использование документов.
> Если хранишь документ целиком, то и собирать его потом из множества кусков не потребуется.
Денормализация может очень даже аукнуться и усложнить поддержку. Забивать на схему не стоит даже несмотря на то, что ДОБД позволяют это делать.
> и не нужно городить костыли в виде ORM
Зато приходится городить костыли в виде ODM. Причем те ODM, которые я видел для mongo (например mongoose для node.js) гораздо более сырые и менее функциональные чем ORM для mysql, (doctrine2 например).
Я не говорю о том, что для реализации CMS нельзя использовать документо-ориентированные базы, я защищаю реляционные базы в том смысле, что их использование мне кажется вполне оправданным на тех самых 80% проектов. Я бы скорее сказал, что документо-ориентированные базы — это в некотором смысле оверкилл для типичных задач. Их 100% удобно использовать там где имеешь дело с неструктурированными данными и нечеткой схемой, но в большинстве случаев, этого как раз и не требуется.
Ок, давайте обсудим. Во-первых, как я понял речь идет все таки о РСУБД, а не об SQL. SQL — всего лишь один из языков запросов. Во-вторых, не очень понятно, о каких задачах идет речь. Если вы говорите о визитках, интернет магазинах и корпоративных сайтах, то обычно самой сложной частью таких приложений является CMS. Таким образом, можно говорить о том, что большинство задач типичного веба требуют реализации CMS (либо взять готовую). Задача уже подразумевает некоторую предметную область включающую как минимум пользователей, роли и ресурсы. ИМХО, реляционные таблицы — вполне адекватный инструмент для такой задачи.
Делал небольшой проектик на socket.io, узким местом на рабочем ноуте (4 ядра 2.4 GHz 6Gb память) становился процессор уже при 3000 одновременных соединений. Залипал именно процесс handshake-а, и что интересно, еще сильнее залипал процесс разрыва большого количества одновременных соединений. Можете сказать, какое количество соединений можно комфортно обслужить одной машиной уровня www.hetzner.de/en/hosting/produkte_rootserver/ex4?
Не знал, что git делался как фреймворк. Это многое объясняет :) Мне кажется, что git цепляет людей именно своей гибкостью и низкоуровневостью. Мне иногда сложно объяснить людям почему стоит использовать git а не svn к примеру, но чисто субъективно после длительной работы с git-ом, все остальное кажется крайне неудобным, хотя вроде бы позволяет настроить вполне нормальный workflow, но чего-то всегда не хватает.
Предвижу порношутки :)
NoSQL поощряет денормализацию, и это кстати один из минусов, т.к. делаться она должна очень аккуратно, что не всегда происходит в реальности.
Денормализация может очень даже аукнуться и усложнить поддержку. Забивать на схему не стоит даже несмотря на то, что ДОБД позволяют это делать.
> и не нужно городить костыли в виде ORM
Зато приходится городить костыли в виде ODM. Причем те ODM, которые я видел для mongo (например mongoose для node.js) гораздо более сырые и менее функциональные чем ORM для mysql, (doctrine2 например).