ООП v.s. Оптимизация

  • Автор темы Автор темы Gigahard
  • Дата начала Дата начала

Gigahard

Новичок
ООП v.s. Оптимизация

Столкнулся я вот с одной дилеммой.
Имеется ОО модель дерева. Каждый узел представляет собой отдельный самостоятельный объект. Соответственно этот объект может самостоятельно взаимодействовать с источником данных - инициализироваться и сохранять данные. Построение и инициализация всего дерева строится на инициализации всех его составляющих объектов.

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

На форуме встречается точка зрения, что это не правильный подход. Что построение дерева должно производится единичным запросом возвращающим всю структуру дерева. А уже потом всю эту структуру "разделывать" как душе угодно.

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

Насколько вообще правильно запрашивать структуру всего дерева, если я хочу получить информацию всего по паре узлов?
 
правильная реализация позволяет сделать выборку как дерева целиком, так и отдельных его ветвей (с указанием уровня вложенности) или листьев.
 
Long
В случае с самостоятельной инициализацией узла, узел берет из БД только те данные, которые к нему относятся. Т.е. сам отвечает за себя и только за себя.
В случае с централизованой выборкой придется предусмотреть все возможные вариант таких выборок. Немного противоречит концепции модульности и взаимной независимости объектов.
 
Что мешает иметь две сущности, а то и три, для работы? Дерево, ветвь, и узел?
Это разные сущности, над которыми будут выполнятся разные действия, почему бы их не разделить?
 
флоппик
Т.е. процедуры выборки из БД отдельно сделать как для листа, так и для ветви и дерева. И процедуры эти сделать независимыми друг от друга...
 
Gigahard, для БД может быть вообще контейнер, у которого будут запрашивать нужные данные о дереве, а он будет решать какие запросы строить. так деревья будут изолированы от реализации их хранилища - хоть в текстовом файле сохраняй про надобности
 
что-то мне подсказывает что мухи и котлеты перемешались :) кто мешает реализовать правильный (подход - дело вкуса и задачи) объект Node, который будет уметь как выбрать только своих потомков, так и потомков потомков (с нужной вложенностью)? только не стоит, на мой взгляд, сразу превращать потомков в объекты - храните как данные. и при необходимости (запрос) формируйте объект.
а перемешалось все потому что задачи разные. в одном случае - нам нужно получить все дерево или отдельные его ветви одним запросом (дабы избежать рекурсии). а в другом - строить дервево частями. однако те же материализованные пути позволят работать в обоих случаях.
 
Long
что-то мне подсказывает что мухи и котлеты перемешались

Именно с таким чувством я и стартовал эту тему :)
 
Gigahard, вообще ООП создано для облегчения разработки. Вся оптимизация лежит вне плоскости ООП. ООП это механизм ускорения реализации абстракции. Вот в грамотности построения абстракции и скрывается оптимизация (с какими сущностями и как вы работаете).
 
По структуре бд, каждый узел знает только своего предка и своих потомков. Собственно такая же структура и объекта "узел".

Это то, что можно сформировать одним запросом.

Если у нас идет запрос типа "узнать всех потомков родительского узла, до последнего уровня вложенности" или "узнать всех предков узла до корня", то тут одним запросом к БД не обойдешся? В случае "одного запроса" придется извлекать всю БД?
 
Gigahard, да у тебя еще и дерево в БД неоптимально храниться. Есть разные к этому подходы, самое важное - что с деревом будет происходить (то есть только читать его, изменять и как и т.п.). Читаем умные книжки про деревья, для начала.
 
Gigahard, на самом деле есть несколько подходов работы с деревьями. Для смежных множеств одним запросом, например, можно получить всех потомков узла или всех родителей. Я же сказал... Всё в вашей абстракции. ООП позволяет создать удобный интерфейс и не более.
 
dimagolov
Ну первое что пришло на ум - аналогия с DOM.

jonjonson
dimagolov
А где нибудь можно посмотреть уже изобретенные велосипеды?
 
dimagolov
Ну так Вы как опытные товарисчи наверное можете поделится дельными ресурсами ;)
 
Krishna
Сидю :)


- Милиция?
- Да.
- Плохо работаете.
...(клац)...
- Как можем, так и работаем :)

Надеюсь Вы не из контрразведки?
:D
 
Gigahard
:)
Я тоже, в ветке про Грузию )
Забавно, как тесен мир)

По существу вопроса - считаю, смотря какие ноды тебе понадобятся. Только те, что загружаешь, или не только.
Тогда и дерево грузишь целиком или по частям.
 
Сверху