Что бы Вы хотели видеть в PHP-фреймворке?

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

в том то и дело, что чуток. База везде одинакова, меняются расширения тем более в php.

Ладно если б там какойнить серверный js

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

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

Также я нигде не встречал INSERT DELAYED, а это крайне полезно для логов и статистики. Многие используют две таблицы - одну в MEMORY, другую на диске, потом по Крону одна копируется в другую и т.д. При этом никто не использует простые решения.

Для отношений Has Many, Belongs To и других используются несколько SELECT, хотя в некоторых случаях INNER JOIN в разы быстрее.

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

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

Просто нет смысла оптимизировать то что *пока* никому не нужно :)

В нем понта примерно ноль на php. Если у Вас скрипт работает по 2 секунды, то инсерт делеед Вас не спасет. А если 0.02 секунды, то смысл от него?

Инсерт делеед хорош при использовании в пхп демонах, когда один и тот же мускул коннект висит по часу. Но где Вы видели это в цмс?

У нас в текущей CMS сделано проще, всё что не требует "мгновенной" реакции тупо сбрасывается в таблицу очередей, откуда потом по крону разбирается. И статистика и логи и все остальное.

Зато масштабируется фигово. При чем иногда до смешного фигово.

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

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

Я так понимаю, использование foreign key для вас вообще смерти подобно, там ведь 100% не получится две таблицы независимо друг от друга разделить :)

Вы понимаете разницу между "вшить в архитектуру foreign key" - как мы сказали... и между "использовать foreign key" - как написали Вы?

Нельзя завязывать приложение/архитектуру на джоинах и прочем. Ибо разделяй и властвуй.

Всегда должна быть возможность, при этом не сильно потеряв в производительности, работать с базовым набором данных "одиночными" выборками.

Я хотел от фрейма, исключительного кеширования в статику тех кто не имеет куки и замену mysql на postgres на лету.

так а в чём будут преимущества? просто мне кажется, что основное преимущество популярных фреймворков в том, что можно заменить программиста...