Как правильно организовать генерацию дерева зависимостей?

Как правильно организовать генерацию дерева зависимостей?

У меня БД с таблицей в которой у меня хранятся зависимостей одних документов от других. Эти данные я использую для генерации дерева документов в TreeView (стуктура конструкторской документации).
Сталкнулся с вопосом оптимального выполнения этого процесса. У меня на примете 2 варианта решения:
1. Запросить из БД сразу все данные и сохранить в список зависимостей (List<Dependency>), а всю выборку проводить при помощи LINQ запросов.
Плюсы:
а. Один запрос к БД
б. Нет необходимости таскать за собой логику работы с СУБД
Минусы:
а. Больший расход ресурсов, особенно если таблица зависимостей большая
б. LINQ запросы дольше (спорно и зависит от количества зависимостей)
2. Запросить из БД данные по необходимости в список зависимостей (List<Dependency>). Всю выборку проводить SQL-запросами.
Плюсы:
а. Малый расход ресурсов вне зависимости от размера таблицы зависимостей
б. Относительно быстрая выборка данных из БД
Минусы:
а. Множество запросов к БД
б. Необходимость таскать за собой логику работы с СУБД

Работа с СУБД ведутся с помощью Dapper, т.е. запросы, выборки и маппинг запросов на класс Dependency.

0

Сообщение от RuS_984 а. Один запрос к БД

Конского размера.

Сообщение от RuS_984 б. Нет необходимости таскать за собой логику работы с СУБД

Этого и так быть не должно. Логика работы с базой должна быть изолирована и доступна по мере необходимости. Ничего таскать не надо.

Сообщение от RuS_984 а. Множество запросов к БД

Ничего страшного, она выдержит, она - молодец.

Сообщение от RuS_984 б. Необходимость таскать за собой логику работы с СУБД

См. выше.

Запрашивайте у базы данные в готовом виде, она на то и СУБД чтобы не только хранилищем выступать (это и файлы обычные умеют), пользуйтесь преимуществами СУБД.

Логику работы с базой выделит в отдельный логический уровень.

0

Сообщение от Usaga Конского размера.

Не такого уж и конского... Таблица на 8 столбцов с JOIN.

Сообщение от Usaga Этого и так быть не должно. Логика работы с базой должна быть изолирована и доступна по мере необходимости. Ничего таскать не надо.

Сообщение от Usaga Логику работы с базой выделит в отдельный логический уровень.

Не так выразился. Не логику работы с СУБД, а соответсвующий репозиторий.

0

RuS_984, лучше сразу запросить нужное.

А что проблематичного в том, чтобы иметь ссылку на репозиторий там, где это нужно?)

0

Сообщение от Usaga А что проблематичного в том, чтобы иметь ссылку на репозиторий там, где это нужно?)

Абсолютно ничего. Мне просто интересно как делают более опытные специалисты.

Сообщение от Usaga RuS_984, лучше сразу запросить нужное

Это вопрос или утверждение? Если утверждение, то получатся возвращение к моей идее разового запроса к БД....

Для построения дерева я использую рекурсивные запросы для каждого подуровня. Соответственно у меня количество запросов (в общем случае) равно количеству подуровней

0

RuS_984, специалисты тящут только то, что нужно. Если предполагается работа с базой - репозиторий, если с данными, то - данные.

Сообщение от RuS_984 Это вопрос или утверждение?

Это утверждение. Если вам сразу нужны все данные, которые вы будете "вертеть" в код, то тащите всё. Если нужно только какое-то подмножество, то только его и берите, не надо тащить всё, а потом фильтровать.

У нас была похожая задачка давно. Мы там вытаскивали только верхний уровень. Все последующие запрашивали по мере надобности. Работает на ура. Но у нас там реально дофига было элементов. Если у вас их не больше сотни, то можно и сразу всё выдернуть и не париться "правильностями".

0

Сообщение от Usaga Мы там вытаскивали только верхний уровень. Все последующие запрашивали по мере надобности.

Я так сделал для MVC-приложения. Получал данные из БД, собирал в JSON и передавал пользователю. А там силами JS и KnockOutJS формировал дерево

0