Меню
Что нового?

Диагноз - ORM :-)

bkonst

bkonst

.. хочется странного?...
Автор оригинала: whirlwind
Неправда Ваша. Задача ОРМ сделать как можно меньше запросов. Если сама она не может угадать в каком случае как удобнее выбирать, значит нужно предоставить удобные средства для программиста. Это возможно когда в конце концов большинство оторвутся от LazyLoad и подумают в сторону BulkLoad ;)
Нажмите для раскрытия...
Обеими руками за Bulkload. Однако даже с Bulkload тормозов при обработке в PHP большого количества записей не обойтись. Предположим, что временные затраты на анализ очередной полученой записи, инициализацию объекта и занесение его в кэш ~0.1ms. Вспоминаем арифметику и получаем, что при обработке 10000 объектов затраты только на из создание составят ~1000ms. Лично мне от этой цифры мучительно больно, а вам? Да, мы можем наворотить многоуровневое кэширование и получить приемлемую скорость (однако своевременное обновление кэша при внесении изменений это тоже та еще задача). А можем сделать более интеллектуальный генератор запросов. Лично я считаю, что первый путь приведет в тупик.

jonjonson
Программисту знающему php и SQL для использования ORM нужно изучать ещё один язык. Построение же запросов через ORM - это написание кода на языке ORM. Вспомните работу с файлами или потоками. ORM ещё сложнее.
Нажмите для раскрытия...
Абсолютно верно. Он сложнее, но может быть и гибче. Пример? Пусть вам необходимо работать со несколькими связанными выборками; например, "продавцы данного отдела с суммой заказов за последние полгода > N", "продавцы данного отдела с суммой заказов за последние полгода > N со стажем работы более X месяцев", "продавцы данного отдела с суммой заказов за последние полгода > N со стажем работы более X месяцев получившие премии за последний месяц" и так далее. В этом случае можно написать три независимых SQL-запроса (получив проблемы при изменении бизнес логики), либо (если ORM достаточно функциональна) создать объект "фильтр" и в процессе получения выборок постепенно добавлять в него новые правила отбора.

Вообще, в ORM интересна не сама по себе (отобразить атрибуты объекта на поля таблицы несложно), а в связи с инструментами. Генератор запросов - один из них.
 
whirlwind

whirlwind

TDD infected, paranoid
bkonst вообще не понимаю про что Вы тут говорите. какой такой кеш, какое создание объекта - setRaw чтоли? Да и самое главное - где вам могут понадобиться сразу 10к объектов, кто их смотреть будет, ваши пользователи? В реальных задачах нужно оценивать. Высоссаные из пальца лично меня мало интересуют.
 
bkonst

bkonst

.. хочется странного?...

atv

Новичок
очень непривычно - что манипуляции мы производим над $orders и $customers, а изменяются $sellers.
Нажмите для раскрытия...
Как ты правильно заметил, это дело привычки :) Это новый подход, поэтому требует привыкания, но зато он, как мне кажеться, более естественнен. Кстати, изменяются не только $sellers, после установки фильтров мы можем забирать итератор из любой коллекции, и, в зависимости от того откуда мы взяли итератор, получаем разные эквиваленты SQL запроса:
Код: 
$sellers->getIterator()
SELECT * FROM sellers JOIN orders USING(seller_id)
    JOIN customers USING(customer_id)
    WHERE order_sum = 100 AND customer_name = 'Customer 1'

$customers->getIterator()
SELECT * FROM customers JOIN orders USING(customer_id)
    JOIN sellers USING(seller_id)
    WHERE order_sum = 100 AND customer_name = 'Customer 1'

$orders->getIterator()
SELECT orders.* FROM sellers JOIN orders USING(seller_id)
    JOIN customers USING(customer_id)
    WHERE order_sum = 100 AND customer_name = 'Customer 1'
гораздо более приятным использованием я вижу что-то типа:

$orders = $seller->getOrders();
foreach ($orders as $concrete_order) {
echo $concrete_order->getCustomer()->getName();
}
Нажмите для раскрытия...
Ты имееш ввиду что вызов метода удобнее чем обращение к свойству?

А можем сделать более интеллектуальный генератор запросов.
Нажмите для раскрытия...
Если б можно было его сделать, так он был бы уже сделан. Проблема в том, что задача не поддаётся формализации (почему, я уже упоминал выше). В результате получаем заплатки и надстройки, которые сами по себе начинают тормозить.
 

Rammstein

PHPClub::News
Сложно, на самом деле, сделать что-то одновременно и универсальное и удобное. К генераторам запросов отношусь крайне негативно, т.к. всё что я видел сделано под туеву хучу баз данных, а впендюрить вызов левой функции (напр, в условие) бывает часто вообще невозможно или возможно, но через задницу.

ИМХО, генератор должен делать только самую общую работу: доступ к свойствам, валидация (это уже спорно) и ещё может чего. Более сложные запросы (связанные с несколькими таблицами) писать только ручками и только SQL.
 
bkonst

bkonst

.. хочется странного?...
Rammstein
впендюрить вызов левой функции (напр, в условие) бывает часто вообще невозможно или возможно, но через задницу.
Нажмите для раскрытия...
Можно (простенький) пример (или пару) такой проблемы? (Для того чтобы знать потребности пользователей).
 
zerkms

zerkms

TDD infected
Команда форума
Ты имееш ввиду что вызов метода удобнее чем обращение к свойству?
Нажмите для раскрытия...
просто если загрузка ленивая - тогда подгрузка будет инициироваться явным образом - т.к. тогда, тогда это действительно нужно + связанные объекты у нас являются результатом работы метода, а не объявленные ранее и магическим образом установленные как у тебя ;)

ps: опять же - это дело привычки
 
Войдите или зарегистрируйтесь для ответа.
Сверху