Stek

Рейтинг
315
Регистрация
23.05.2004
Что бы Вы хотели видеть в PHP-фреймворке?
livetv:
А если условие по 2 и более таблицам, как избавиться от джойнов?

а нафига от них избавляться ? Ну грубо говоря

# любителям SELECT
$rs = post->get->last()
for ($author in $rs) {
$last_post = $author->last_post();
print "{$author->name}: {$last_post->title}"
}

# любителям JOIN
$rs = post->get->last()->related('author');
for ($row in $rs) {
print "{$row->author->name}: {$row->title}";
}

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

Что бы Вы хотели видеть в PHP-фреймворке?
edogs:
А модель базы чем диктуется? Правильно, архитектурой. А что нельзя завязывать на форежн? Правильно, архитектуру.

Это сейчас тролинг такой или же вы на полном серьезе это говорите ?

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

Я вообще вашей первой части не понимаю. foreign key относится к модели базы, например: "аккаунт -> статья -> комментарий" или "товар -> фотография". Миллионы различных вариантов, все зависит от желания разработчика.

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

При чем тут архитектура если выборкой должен ORM заниматься. И от реализации этого ORM и будет зависеть, JOIN там или SELECT.

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

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

Что бы Вы хотели видеть в PHP-фреймворке?
proksey-net:
А mysqli уже не котируется?

тогда особо и смысла в ORM нет, если все завязано на один драйвер.

proksey-net:
Устраивает, просто основные элементы популярных типов сайта (типа блоги), такие как пагинация и т.д. я делаю сразу в ядре, чтобы каждый раз не писать кучу кода.

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

MySQL. Как влияет на производительность объединение таблиц?
feanorr-V:
На скорость никак не повлияет, так как все эти таблицы "физически" хранятся в одном файле

"В одном файле" - это если используется innodb . Ну и какая разница, один файл или несколько, если скорость выборки зависит от числа строк в таблице, числа индексов и прочего.

Может как повлиять, так и вообще не повлиять.

Что бы Вы хотели видеть в PHP-фреймворке?
Оптимизайка:
Eloquent слишком большой и тяжелый?

182 файла весом в 1 мег - на понятие "маленький" не тянет.

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

Кто бы хотя бы маленький и легкий ORM написал, без тонны зависимостей, генерируемых файлов и т.п. Желательно через PDO.

Как я изучал английский язык.
Artisan:
Кто хотел,
тот учился.

Ага, особенно те, кто изучал немецкий в школе. Им коротковолник на английском наверное ну офигеть как помогал :D

Как я изучал английский язык.

Учил немецкий в школе. Английский знаю на уровне программирования и тех. документации. Даже в игровых стримах индусов понимаю :) Но вот пару раз пришлось голосом на английском в скайпе общаться - сбросил пару килограммов.

Завидую нынешним школьникам - английский в обучении, живая среда в интернете, практики море. А не то что ты "Bitte diese door offen" :D

1... 129130131132133134135136137 ...277
Всего: 2766