Эта реализация dot notation не поддерживает группирования, потому проверяется возможность собрать массив результатов, в котором для одной книги ровно один автор
В любом случае спасибо за потраченное время. Вот результаты:
Нет, я не предлагаю пользоваться моими сущностями, пишите свои. Классы сущностей приведенные в примере не являются частью описываемой библиотеки.
Eloquent — реализация патерна ActiveRecord, классы сущностей в примере — крайне упрощенная реализация патерна DataMapper, немного разные вещи.
Ускорить инициализацию моделей Eloquent у меня вряд ли получиться (без применения костылей), но если вдруг так вышло что в вашем проекте ну никак не обойтись без Eloquent, то придется либо смириться с его скоростью либо костылить.
На скорость работы библиотеки влияет не количество полей в таблице, а сколько полей указано в секции SELECT запроса. И если вдруг так получилось, что в секции SELECT запроса оказалось 100+ полей, возможно скорость просядет, но не факт (еще раз отмечу — я не претендую на создание на 100% универсального решения). В любом случае стенд для испытаний выложен на гитхаб, каждый может развернуть его у себя и потестить.
При джойнах скорость просядет при большой глубине вложенности данных и при этом высокой уникальности вложенных данных. В этом случае стоит попробовать достать данные несколькими WHERE IN запросами (как это делает тот же Eloquent), но не уверен, что поможет.
Помимо того что в Eloquent немного толще превращение в объект, чеснее было бы сравнивать с Model::hydrate, например.
Не понял что именно сравнить с Model::hydrate
вы ускорили конкретно ваш юзкейс
Не совсем так. Да — скорость обработки зависит от структуры данных, и, возможно, существуют ситуации где использование другой ОРМ предпочтительней. Я тестировал скорость работы библиотеки на различных данных, но расписывать их все в одной статье слишком долго (даже короткие статьи не все читают внимательно).
у вас один автор — одна книга
Нет, в примере связь many-to-many
Все в тот же огород камень, к сожалению у сущностней поля далеко не 3
Количество полей и глубина вложенности никак не ограничена
все будет еще печальнее с джоинами.
В статье пример с джойнами
Третье это то, что например таблица с авторами и таблица с книгами могут вообще находится в разных БД или даже серверах.
Я не претендую на создание на 100% универсального решения, эдакой «серебряной пули»
Четвертое это не удобно, а laravel это больше про удобство чем про погоню за ms (которые можно выиграть другими способами)
Удобство — вещь относительная. Laravel — это скорее больше про компромисс между удобством и скоростью.
Кстати, а почему именно Laravel? Да, в примере сравнение производилось с Eloquent, но ведь нигде не сказано, что использование библиотеки ограничивается лишь использованием в проектах на Laravel.
загружай список книжек один раз в кеш в памяти и переиспользуй
В этом случае встает вопрос инвалидации кэша.
вашу задачу конвертации результата в дерево я бы решил стандартными способами без сторонних библиотек:
Пример с книжками — лишь пример.
Полей (столбцов) в выдаче может быть сколь угодно, вложенность (структура) данных может какой угодно, эти параметры могут варьироваться создавая множество вариантов реализации приведенного вами метода.
Также не исключается случай изменения порядка столбцов в выдаче.
В проекте помимо книжек и авторов, например, может быть еще сотни сущностей и для каждой придется писать свой индивидуальный метод обработки массива.
Здесь скорее по ситуации. В примере (при замере скорости) я грузил данные из массива в объекты, но лишь для чистоты эксперимента, поскольку от Eloquent, с которым производилось сравнение, мы получаем также коллекцию объектов а не массив.
Имеется ли у make возможность запросить у пользователя параметр, затем запомнить его для использования при запуске уже других команд в последствии? Как, например, параметр 'appName' при запуске '1. Build', затем '2. Deploy and Up', а затем и '4. Stop' в примере приведенном в статье.
не удержался ))
В любом случае спасибо за потраченное время. Вот результаты:
Новый результат
Eloquent — реализация патерна ActiveRecord, классы сущностей в примере — крайне упрощенная реализация патерна DataMapper, немного разные вещи.
Ускорить инициализацию моделей Eloquent у меня вряд ли получиться (без применения костылей), но если вдруг так вышло что в вашем проекте ну никак не обойтись без Eloquent, то придется либо смириться с его скоростью либо костылить.
На скорость работы библиотеки влияет не количество полей в таблице, а сколько полей указано в секции SELECT запроса. И если вдруг так получилось, что в секции SELECT запроса оказалось 100+ полей, возможно скорость просядет, но не факт (еще раз отмечу — я не претендую на создание на 100% универсального решения). В любом случае стенд для испытаний выложен на гитхаб, каждый может развернуть его у себя и потестить.
При джойнах скорость просядет при большой глубине вложенности данных и при этом высокой уникальности вложенных данных. В этом случае стоит попробовать достать данные несколькими WHERE IN запросами (как это делает тот же Eloquent), но не уверен, что поможет.
Не понял что именно сравнить с Model::hydrate
Не совсем так. Да — скорость обработки зависит от структуры данных, и, возможно, существуют ситуации где использование другой ОРМ предпочтительней. Я тестировал скорость работы библиотеки на различных данных, но расписывать их все в одной статье слишком долго (даже короткие статьи не все читают внимательно).
Нет, в примере связь many-to-many
Количество полей и глубина вложенности никак не ограничена
В статье пример с джойнами
Я не претендую на создание на 100% универсального решения, эдакой «серебряной пули»
Удобство — вещь относительная. Laravel — это скорее больше про компромисс между удобством и скоростью.
Кстати, а почему именно Laravel? Да, в примере сравнение производилось с Eloquent, но ведь нигде не сказано, что использование библиотеки ограничивается лишь использованием в проектах на Laravel.
Нет
Не совсем понятно что значит в «сыром»
Да, получаете данные в более удобном виде, чем плоский массив, а что делать с ними дальше решаете по ситуации
Добавлю, но чуть позже (или не чуть). Возможно вот эта страница даст представление об относительном быстродействии различных ОРМ.
В этом случае встает вопрос инвалидации кэша.
Пример с книжками — лишь пример.
Полей (столбцов) в выдаче может быть сколь угодно, вложенность (структура) данных может какой угодно, эти параметры могут варьироваться создавая множество вариантов реализации приведенного вами метода.
Также не исключается случай изменения порядка столбцов в выдаче.
В проекте помимо книжек и авторов, например, может быть еще сотни сущностей и для каждой придется писать свой индивидуальный метод обработки массива.
Пожалуй нет.
Здесь скорее по ситуации. В примере (при замере скорости) я грузил данные из массива в объекты, но лишь для чистоты эксперимента, поскольку от Eloquent, с которым производилось сравнение, мы получаем также коллекцию объектов а не массив.
Да, пожалуй можно было и 'author.name'.
опечатка, да в $config 'prefix' => 'book_'. Спасибо что заметили, исправил