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

CP
На сайте с 12.08.2009
Offline
101
#21
worldofproxy:
А по сути - всего уже написано. Допиливаются лишь детали и фичи, точнее расширяются уже на базе готовых

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

Профессиональный frontend: JS, html,css, Single-Page App (/ru/forum/964386)
W
На сайте с 26.08.2010
Offline
42
#22
Content-pro:
...чуток не похожее...

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

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

Прокси сервис http(s), socks(4/5) с ежеминутным обновлением списков (http://worldofproxy.com/)
PN
На сайте с 22.08.2012
Offline
103
#23
Content-pro:
Это к любой сфере можно отнести, все фильмы уже отсняты, вся музыка записана, но постоянно появляется что новое, чуток не похожее на старое и которое всем нравиться)

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

edogs:
Одна из причин то, что count(*) более универсален, чем sql_calc. Вторая несомненно в том, что sql_calc мало кто знает:)

Однако теоретическое объяснение шустрости в принципе на поверхности.
sql_calc перебирает всю таблицу (точнее ее остатки), что бы посчитать количество записей.
В то время как count(*), при условии наличия индекса, в таблицу не полезет, он возьмет все данные непосредственно из индекса, что даст хороший результат по скорости.

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

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

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

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

Мой совет помог? Не скупись! Bitcoin 1Lseddet1o1B6odgXQHbGaWGwRkt1Db8Ef Ethereum 0x450f1a17461e25194B7F9226cDEe70173F39e1e1
CP
На сайте с 12.08.2009
Offline
101
#24
proksey-net:
Я прихожу к выводу, что уже забывают про понятие оптимизации и стремятся максимально все абстрагировать, чтобы создать идеальный MVC-фреймворк. Потом пытаются ускорить неоптимизированный движок кэшированием. А проще сразу создавать правильные запросы.

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

Оптимизайка
На сайте с 11.03.2012
Offline
396
#25

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

⭐ BotGuard (https://botguard.net) ⭐ — защита вашего сайта от вредоносных ботов, воровства контента, клонирования, спама и хакерских атак!
edogs software
На сайте с 15.12.2005
Offline
771
#26
proksey-net:
Также я нигде не встречал INSERT DELAYED
, а это крайне полезно для логов и статистики.

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

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

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

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

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

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

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

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

Разработка крупных и средних проектов. Можно с криптой. Разумные цены. Хорошее качество. Адекватный подход. Продаем lenovo legion в спб, дешевле магазинов, новые, запечатанные. Есть разные. skype: edogssoft
S
На сайте с 23.05.2004
Offline
305
#27
edogs:
Не, если иннер джоин именно в разы быстрее, то можно обыграть как-то архитектуру вокруг этого, сделать нечто вроде кэширования, но нельзя вшивать это в саму архитектуру. Потому что когда Вам понадобится одну таблицу скинуть на один сервер, другую на другой, а у Вас джоины по обоим - Вы застреллитесь.

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

Это просто подпись.
edogs software
На сайте с 15.12.2005
Offline
771
#28
Stek:
Я так понимаю, использование foreign key для вас вообще смерти подобно, там ведь 100% не получится две таблицы независимо друг от друга разделить :)

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

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

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

kxk
На сайте с 30.01.2005
Offline
972
kxk
#29

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

Ваш DEVOPS
IPXI
На сайте с 04.11.2015
Offline
126
#30
proksey-net:
Что бы Вы хотели видеть в PHP-фреймворке?
Уважаемые форумчане! Разрабатываю многофункциональный фреймворк, который не должен уступать популярным фреймворкам...

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

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий