Как сохранить каталог / иерархия / древовидная структура в базе данных?
Для тех, кто задается вопросом, где другие потоки, ссылающиеся на класс Deadlock, Java lambdas ведут себя так, как вы написали это:
public class Deadlock {
public static int lambda1(int i) {
return i;
}
static {
IntStream.range(0, 10000).parallel().map(new IntUnaryOperator() {
@Override
public int applyAsInt(int operand) {
return lambda1(operand);
}
}).count();
System.out.println("done");
}
public static void main(final String[] args) {}
}
С обычными анонимными классами нет взаимоблокировки:
public class Deadlock {
static {
IntStream.range(0, 10000).parallel().map(new IntUnaryOperator() {
@Override
public int applyAsInt(int operand) {
return operand;
}
}).count();
System.out.println("done");
}
public static void main(final String[] args) {}
}
6 ответов
Существуют много путей для хранения иерархий в базах данных SQL. Какой выбрать зависит, на котором продукте DBMS Вы используете, и как данные будут использоваться. Поскольку Вы использовали тег MSSQL2005, я думаю, что необходимо начать рассматривать модель "Adjacency List"; если Вы находите, что это не работает хорошо для Вашего приложения, то взглянуло на сравнение Vadim Tropashko , который выделяет различия между моделями с вниманием на несколько рабочих характеристик.
При использовании SQL-сервера 2008 является опцией: возможно, необходимо проверить новый тип данных hierarchyid .
Также существует Модель Вложенного Набора Деревьев, которая имеет некоторые преимущества перед моделью ParentID. См. http://www.evanpetersen.com/item/nested-sets.html и http://falsinsoft.blogspot.nl/2013/01/tree-in-sql-database-nested-set-model.html
Это - больше закладки для меня, чем вопрос, но она могла бы помочь Вам также. Я использовал подход этой статьи для хранения каталога / древовидная структура в базе данных.
существуют некоторые полезные фрагменты кода в статье также.
Hope это помогает.
я не аффилирован с тем веб-сайтом всегда
Вы используете SQL Server 2005? Рекурсивные запросы делают запросы иерархических данных намного более изящными.
Редактирование: Я действительно думаю, что осуществленные пути являются определенным взломом. Путь содержит ненормализованные избыточные данные, и необходимо использовать триггеры или что-то для держания их в курсе. Например, если узел изменяет родителя, целое поддерево должны были обновить их пути. И запросы поддерева должны использовать некоторое ужасное соответствие подстроки, а не изящное и быстрое соединение.
Типичным путем является таблица с внешним ключом (например, "ParentId") на себя.