OOП и количество запросов к БД

[akxxiv]

OOП и количество запросов к БД

Что-то я в ООП торможу... Откуда ни посмотрю - расход ресурсов...
Ситуация такая. Заказчик формирует заказ логистической компании на перевозку груза в разные города и в разные магазины.
В данные заказы добавляются накладные, которые имеют номер, дату, пункт доставки, количество и сумму груза. Соответственно для хранения информации используются

1. Таблица заказчиков - customers

id      - id заказчика
name    - наименование заказчика
.....

2. Таблица заказов - orders

id      - id заказа, он же номер заказа 
date    - Дата заказа

3. Таблица городов - cities

id      - id города
name    - Имя города

4. Таблица сторговых сетей - nets

id      - id сети
name    - Имя сети

5. Tаблица магазинов - deliveryPoints

id      - id магазина
name    - Имя магазина
net_id  - id сети, к которой принадлежит магазин
city_id - шв города

6. Tаблица накладных - waybills

id            - id накладной
number        - номер накладной
date          - дата накладной
num_pallets   - количество палет
sum           - сумма
order_id      - id заказа к которому принадлежит накладная
dp_id         - id пункта доставки (магазина)

Вот. Это упрощенная структура данных. Теперь нужно выбрать список накладных, в котором будут указаны имя заказчика и полное название пункта доставки (Города::Сеть::Магазин). Сейчас я просто составляю запрос к БД с 5-тью джойнами и обрабатываю массив. А если это делать посредством ООП?
Что имеем объект накладные с методами

$waybill = new waybill($i);
$waybill->getNumber();
$waybill->getDate();
$waybill->getSum();

Здесь все ясно, в при инициализации идет выборка из БД а затем просто отдаются значения.

$waybill->getDp();

А вот здесь скорее всего создается объект Пункта доставки, который считывает из БД свои параметры, который в свою очередь создает объекты городов и сетей, это уже 4 запроса к БД.

А для выборки Заказчика из накладной нужно действовать через объект заказа, а это еще 2 запроса. И нужно вывести список из 50 накладных....

Этож сколько запросов???

Или я совсем не догоняю. Как проектируются такие системы на ООП???

 

[Vallar_ultra]

Поищи инфу по шаблонам проектирования.... По-моему здесь неплохо прокатит "Facade"....

 

[whirlwind]

А если это делать посредством ООП?

вариант 1

$использоватьОтложеннуюЗагрузку=false;
$waybill = new waybill($i,$использоватьОтложеннуюЗагрузку);

вариант 2

$waybill = new waybill();
$waybill->методЗагрузкиВсехСсылочных($i);

для N-колва счетов используются итераторы. Все зависит от того, что за схема у тебя под waybill. На том уровне абстракции что ты рассмтриваешь, тебя уже не должно волновать сколько запросов это будет стоить.

 

[Vallar_ultra]

whirlwind
>не должно волновать сколько запросов это будет стоить.

Это уже вопрос производительности.... Он кстати влияет и на выбор схемы для имплементации...

 

[whirlwind]

Vallar_ultra читать вдумчиво

На том уровне абстракции что ты рассмтриваешь, тебя уже не должно волновать сколько запросов это будет стоить.

Ты еще такты процессора на уровне бизнес-модели начни считать.

 

[akxxiv]

Так вот мне и мнтересно как проектируют тот другой уровень абстрации, на котором как раз и идет выборка.

 

[demongloom]

Мне тоже интересно, т.к. стою перед такой же задачей.

 

[atv]

Сейчас я просто составляю запрос к БД с 5-тью джойнами и обрабатываю массив. А если это делать посредством ООП?

Мне тоже интересно, т.к. стою перед такой же задачей.

В последнее время на форуме участились разговоры по ORM vs SQL, которые заходят в тупик. Я внимательно изучал аргументы за и против с обеих сторон и, похоже, нашёл точку примирения.

Возможно это подразумевалось в разговорах, но небыло высказано вслух, поэтому выскажу я.

Дело в том, что у ORM и SQL разные задачи. SQL предназначен для выборки данных и ПРЕДСТАВЛЕНИЯ их человеку для последующего АНАЛИЗА. Отсюда и вытекают все существующие возможности SQL.

ORM, в свою очередь, предназначен для СОХРАНЕНИЯ СОСТОЯНИЯ объектов приложения. Приложению приходиться работать с объектами, состояние которых должно сохраняться после завершения работы приложения.

Есть много сопобов сохранять состояние объектов, один из которых, сохранение в реляционной базе данных. Так как часто одни и теже данные бывают нужны и для представления человеку и для самого приложения, то способ хранения состояния объектов в БД становиться очень удобным.

Так как для общения с БД есть только один способ - SQL, то ORM просто вынужден им пользоваться. Однако, это не означает что ORM обязан поддерживать все возможности SQL.

Исходя из вышесказанного, стремление полностью отказаться в приложении от SQL совершенно необоснованно. Стремление запихнуть в ORM все возможности SQL также необоснованно, так как ORM не предназначен для этого. В приложении нужно использовать два подхода, в зависимости от того, кому предназначены данные, приложению или для отображения.

 

[demongloom]

ATV, ты прав насчет ОРМ и СКЛ.
Но народу требуется примерный алгоритм реализации кэширования и снижение кол-ва запросов к базе при реализации объектной модели.

 

[zerkms]

demongloom
конеретного аглгоритма не существует - почитать книжки про орм и поглядеть существующие решения, вот что может помочь

 

[demongloom]

Я пока пришел к выводу что кэшировать нужно на уровне смартей и подобной хрени. Это если имею дело со статичными и малоизменяемыми данными. Ну еще использовать кэш запросов в самом mysql.