- PVSM.RU - https://www.pvsm.ru -
Сразу оговорюсь, это не обучающий пост и не провозглашение новой парадигмы )), скорее решение, к которому я пришел, и хочется его обсудить в широкой и честной дискуссии.
Теперь к сути, представьте, что есть некая ORM, написанная на PHP, в которой описана модель Posts, имеющая связи многие-ко-многим через промежуточные таблицы с другими моделями: Comments, Tags, Categories. Вопрос в том, каким способом лучше поднимать связанные данные, всё сразу или с отложенной загрузкой?
В сообществе БД преобладает мнение, что данные лучше поднимать одним запросом с кучей join'ов, мол СУБД умная, она сама разберет, как быстрее всего это сделать и чем меньше запросов к базе тем лучше. В моей же практике были случаи, когда на высоконагруженных проектах с большими таблицами несколько простых запросов работали быстрее, чем один большой с несколькими объединениями.
Со стороны ORM подъем всех данных одним запросом тоже не лучший вариант, потому что, почти всегда, будут подниматься лишние данные, которые в этом месте не нужны (или даже могут помешать, и тогда их еще придется удалять из набора), либо надо иметь набор методов вроде findWithComments, findWithCategoriesAndTags, findWithAllRelations с неизбежным дублированием.
Таким образом, имеем три способа загрузки связей (методы модели):
Если говорить о проектировании какой-то универсальной ORM, последний вариант мне представляется более правильным, причем другого подхода ORM не должна позволять. Расскажу о преимуществах.
Слабое звено такой жесткой изоляции моделей — как делать гибкий поиск сразу по многим критериям, например постов по тегам и категориям.
В общем, приглашаю к дискуссии, какие еще есть минусы, может кто-то приходил / уходил от такого решения, использовали бы вы такую ORM в ваших проектах?
Автор: bardex
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/php-2/38357
Ссылки в тексте:
[1] Источник: http://habrahabr.ru/post/186132/
Нажмите здесь для печати.