Комментарии 4
Скажите, а вам точно была нужна структура Nested Sets? "Квадратичная" природа этой структуры данных автоматически устанавливает ограничение на количество записей в дереве, а раз этих записей мало — с ними проще работать полностью в памяти, а БД использовать только как хранилище.
Если же точно решили его использовать эту структуру — как вообще могло прийти в голову выбирать все записи в память, там их модифицировать, а потом сохранять, да ещё и в два этапа? Ну не подходит Entity Framework для работы с этой структурой данных, надо сырыми SQL-запросами с не работать, это очевидно же. Или можно Linq2Db взять если сырые запросы не нравятся.
Да, соглашусь, на чистом SQL модифицировать дерево было бы проще, и мы бы не столкнулись с проблемами обновления индексов. Возможно это станет очередным этапом оптимизации сервиса, спасибо за комментарий.
Очень дорогие получаются операции модификации дерева. Если как вы говорите деревья у вас небольшие, то имхо эффективнее использовать materialized paths
Модификации дорогие, но мы сознательно пошли на это, т.к. приходится делать не так часто. Но поиск дочерних элементов и поддерева — то, ради чего все затевалось — все же, на мой взгляд, по скорости будет быстрее при сравнении двух числовых колонок, нежели при поиске элемента в пути.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Выращивание Nested sets в условиях .Net