Иерархические метки на SQL
Здесь нет терминальной операции, поэтому этот поток не будет выполнен; таким образом «неиспользованная» ошибка сонара.
У вас также есть побочные эффекты в: id -> groupDTO.getTeamMembers().add(userMap.get(id)
есть лучшие способы решить эту проблему:
List<String> teamMembers = group.getTeamMemberIds() // I assume String here...
.stream()
.map(userMap::get)
.filter(Objects::notNull)
.collect(Collectors.toList());
groupDTO.getTeamMembers().addAll(teamMembers);
Вам почти никогда не нужно containsKey, а затем [113 ] - вы можете избежать двух поисков по хешу, выполнив get и посмотреть, не является ли результат null
5 ответов
Ответ Ali имеет ссылку на Деревья Joe Celko и Иерархии в SQL для Присяжных острословов, который подтверждает мое подозрение - нет простой структуры базы данных, которая предлагает лучший из всех миров. Лучшее для моей цели, кажется, "Частое Дерево Вставки", детализированное в этой книге, которая похожа на "Вложенную Модель Набора" ссылки Ali, но с непоследовательной индексацией. Это позволяет O (1) вставка (а-ля неструктурированная ОСНОВНАЯ нумерация строк) со случайной индексной реорганизацией как и, когда необходимый.
Я реализовал его использование два столбца. Я упрощаю его здесь немного, потому что я должен был сохранить имя тега в отдельном поле/таблице, потому что я должен был локализовать его для различных языков:
- тег
- путь
Посмотрите на эти строки, например:
tag path
--- ----
database database/
mysql database/mysql/
mysql4 database/mysql/mysql4/
mysql4-1 database/mysql/mysql4-1/
oracle database/oracle/
sqlserver database/sqlserver/
sqlserver2005 database/sqlserver/sqlserver2005/
sqlserver2005 database/sqlserver/sqlserver2008/
и т.д.
Используя like оператор на поле трактов можно легко получить все необходимые строки тега:
SELECT * FROM tags WHERE path LIKE 'database/%'
Существуют некоторые детали реализации как то, когда Вы перемещаете узел в иерархию, необходимо изменить всех детей слишком и т.д., но это не твердо.
Также удостоверьтесь, что длина Вашего пути является достаточно большой - в моем случае, я использовал не имя тега для пути, но другого поля, чтобы удостовериться, что я не получаю слишком длинные пути.
Вы могли создать то, что Kimball называет Таблицей Помощника Иерархии.
Скажите, что Вы иерархия похожа на это:-> B | B-> C | C-> D
Вы вставили бы записи в таблицу, которая похожа на это
ParentID, ChildID, Depth, Highest Flag, Lowest Flag
A, A, 0, Y, N
A, B, 1, N, N
A, C, 2, N, N
A, D, 3, N, Y
B, B, 0, N, N
B, C, 1, N, N
B, D, 2, N, Y
C, C, 0, N, N
C, D, 1, N, Y
D, D, 0. N, Y
Я думаю, что имею, это исправляет.... так или иначе. Точка - Вы, все еще хранят Вас иерархия правильно, Вы просто создаете эту таблицу ИЗ своей надлежащей таблицы. ЭТА таблица запрашивает как Банши. Скажите, что Вы хотите знать, какой весь первый уровень ниже B.
WHERE parentID = 'B' and Depth = 1
Я использовал бы некоторый массив для хранения дочерних тэгов, это должно быть намного быстрее, чем присоединение к таблице на себе (особенно, если у Вас есть большое количество тегов). Я взглянул, и я не могу сказать, имеет ли mysql собственный тип данных массива, но можно эмулировать это при помощи столбца текста и хранения сериализированного массива в нем. Если Вы хотите ускорить вещи далее, необходимо смочь поместить текстовый индекс поиска на тот столбец для обнаружения, какие теги связаны.
[Редактирование] После чтения статьи Ali, я сделал еще некоторый поиск и нашел эту презентацию набора подходов для реализации иерархий в пост-ГРЭС. Могло бы все еще быть полезным в объяснительных целях.