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.
edogs: Вы понимаете разницу между "вшить в архитектуру foreign key" - как мы сказали... и между "использовать foreign key" - как написали Вы?
Я вообще вашей первой части не понимаю. foreign key относится к модели базы, например: "аккаунт -> статья -> комментарий" или "товар -> фотография". Миллионы различных вариантов, все зависит от желания разработчика.
edogs: Нельзя завязывать приложение/архитектуру на джоинах и прочем. Ибо разделяй и властвуй.
Всегда должна быть возможность, при этом не сильно потеряв в производительности, работать с базовым набором данных "одиночными" выборками.
При чем тут архитектура если выборкой должен ORM заниматься. И от реализации этого ORM и будет зависеть, JOIN там или SELECT.
edogs: Не, если иннер джоин именно в разы быстрее, то можно обыграть как-то архитектуру вокруг этого, сделать нечто вроде кэширования, но нельзя вшивать это в саму архитектуру. Потому что когда Вам понадобится одну таблицу скинуть на один сервер, другую на другой, а у Вас джоины по обоим - Вы застреллитесь.
Я так понимаю, использование foreign key для вас вообще смерти подобно, там ведь 100% не получится две таблицы независимо друг от друга разделить :)
тогда особо и смысла в ORM нет, если все завязано на один драйвер.
proksey-net: Устраивает, просто основные элементы популярных типов сайта (типа блоги), такие как пагинация и т.д. я делаю сразу в ядре, чтобы каждый раз не писать кучу кода.
А зачем это делать в ядре, если можно сделать как плагин. В ядре вообще ни каких элементов сайта быть не должно. Ядро должно обеспечивать возможность подключения плагинов, валидацию данных, роутинг и т.п.
feanorr-V: На скорость никак не повлияет, так как все эти таблицы "физически" хранятся в одном файле
"В одном файле" - это если используется innodb . Ну и какая разница, один файл или несколько, если скорость выборки зависит от числа строк в таблице, числа индексов и прочего.
Учил немецкий в школе. Английский знаю на уровне программирования и тех. документации. Даже в игровых стримах индусов понимаю :) Но вот пару раз пришлось голосом на английском в скайпе общаться - сбросил пару килограммов.
Завидую нынешним школьникам - английский в обучении, живая среда в интернете, практики море. А не то что ты "Bitte diese door offen" :D
А если условие по 2 и более таблицам, как избавиться от джойнов?
а нафига от них избавляться ? Ну грубо говоря
$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.
А модель базы чем диктуется? Правильно, архитектурой. А что нельзя завязывать на форежн? Правильно, архитектуру.
Это сейчас тролинг такой или же вы на полном серьезе это говорите ?
Вы понимаете разницу между "вшить в архитектуру foreign key" - как мы сказали... и между "использовать foreign key" - как написали Вы?
Я вообще вашей первой части не понимаю. foreign key относится к модели базы, например: "аккаунт -> статья -> комментарий" или "товар -> фотография". Миллионы различных вариантов, все зависит от желания разработчика.
Нельзя завязывать приложение/архитектуру на джоинах и прочем. Ибо разделяй и властвуй.
Всегда должна быть возможность, при этом не сильно потеряв в производительности, работать с базовым набором данных "одиночными" выборками.
При чем тут архитектура если выборкой должен ORM заниматься. И от реализации этого ORM и будет зависеть, JOIN там или SELECT.
Не, если иннер джоин именно в разы быстрее, то можно обыграть как-то архитектуру вокруг этого, сделать нечто вроде кэширования, но нельзя вшивать это в саму архитектуру. Потому что когда Вам понадобится одну таблицу скинуть на один сервер, другую на другой, а у Вас джоины по обоим - Вы застреллитесь.
Я так понимаю, использование foreign key для вас вообще смерти подобно, там ведь 100% не получится две таблицы независимо друг от друга разделить :)
А mysqli уже не котируется?
тогда особо и смысла в ORM нет, если все завязано на один драйвер.
Устраивает, просто основные элементы популярных типов сайта (типа блоги), такие как пагинация и т.д. я делаю сразу в ядре, чтобы каждый раз не писать кучу кода.
А зачем это делать в ядре, если можно сделать как плагин. В ядре вообще ни каких элементов сайта быть не должно. Ядро должно обеспечивать возможность подключения плагинов, валидацию данных, роутинг и т.п.
На скорость никак не повлияет, так как все эти таблицы "физически" хранятся в одном файле
"В одном файле" - это если используется innodb . Ну и какая разница, один файл или несколько, если скорость выборки зависит от числа строк в таблице, числа индексов и прочего.
Может как повлиять, так и вообще не повлиять.
Eloquent слишком большой и тяжелый?
182 файла весом в 1 мег - на понятие "маленький" не тянет.
Кто бы хотя бы маленький и легкий ORM написал, без тонны зависимостей, генерируемых файлов и т.п. Желательно через PDO.
Кто хотел,
тот учился.
Ага, особенно те, кто изучал немецкий в школе. Им коротковолник на английском наверное ну офигеть как помогал :D
Учил немецкий в школе. Английский знаю на уровне программирования и тех. документации. Даже в игровых стримах индусов понимаю :) Но вот пару раз пришлось голосом на английском в скайпе общаться - сбросил пару килограммов.
Завидую нынешним школьникам - английский в обучении, живая среда в интернете, практики море. А не то что ты "Bitte diese door offen" :D