Быстро Реляционный метод того, чтобы хранить древовидные данные (например, распараллелил комментарии к статьям),
Как правило, вы хотите иметь флаг «выполнено» или «проверено» на отдельных элементах дел, что-то вроде:
const todoList = [
{
name: 'Grab some food',
done: false
},
{
name: 'Start coding',
done: false
}
];
А в Vue.js вы можете сделать переключение класса с v-bind:class , а не троичный оператор:
export default {
data() {
return {
//checked: false,
activeList: {
listItems: [
{
name: 'Grab some food',
done: false
},
{
name: 'Start coding',
done: false
}
]
}
}
},
methods: {
checkTaskDone(item) {
//if (this.checked == false) {
// this.checked = true;
//}
//else if (this.checked == true) {
// this.checked = false;
//}
// Check/uncheck
item.done = !item.done;
}
}
}
{{ index + 1 }}. {{ listItem }}
check_round
Кстати, я добавляю индекс для отдельных элементов i.f7-icons, потому что идентификатор должен быть уникальным, в противном случае, пожалуйста, используйте class вместо.
5 ответов
Мне очень нравится, как Drupal решает эту проблему. Каждому комментарию присваивается идентификатор потока. Этот идентификатор начинается с 1 для первого комментария. Если к этому комментарию добавляется ответ, ему присваивается идентификатор 1.1 . Ответ на комментарий 1.1 имеет идентификатор потока 1.1.1 . Родственнику комментария 1.1 дается идентификатор потока 1.2 . Вы уловили идею. Вычисление этих идентификаторов потоков может быть легко выполнено с помощью одного запроса при добавлении комментария.
Когда поток отображается, все комментарии, принадлежащие потоку, выбираются в одном запросе, отсортированном по идентификатору потока. Это дает вам потоки в порядке возрастания. Кроме того, используя идентификатор потока, вы можете найти уровень вложенности каждого комментария и сделать для него соответствующий отступ.
1
1.1
1.1.1
1.2
1.2.1
Есть несколько проблем, которые необходимо решить:
- Если один из компонентов идентификатора потока увеличивается до 2 цифр, сортировка по идентификатору потока не приведет к ожидаемому порядку. Простым решением является обеспечение того, чтобы все компоненты идентификатора потока были дополнены нулями, чтобы иметь одинаковую ширину.
- Сортировка по убывающему идентификатору потока не дает ожидаемого убывающего порядка.
Drupal решает первую проблему более сложным способом с использованием системы нумерации, называемой vancode. Что касается второй проблемы, то она решается добавлением обратной косой черты (код ASCII которого больше цифр) к идентификаторам потоков при сортировке по убыванию.
К сожалению, методы чистого SQL для этого довольно медленные.
NESTED SETS , предложенные @Marc W , довольно элегантны, но они может потребоваться обновление всего дерева, если ветви вашего дерева попадают в диапазон, что может быть довольно медленным.
См. эту статью в моем блоге о том, как сделать это быстро в MySQL :
- Иерархические запросы в MySQL - эмуляция
OracleCONNECT BY
You »Мне нужно создать функцию:
CREATE FUNCTION hierarchy_connect_by_parent_eq_prior_id(value INT) RETURNS INT
NOT DETERMINISTIC
READS SQL DATA
BEGIN
DECLARE _id INT;
DECLARE _parent INT;
DECLARE _next INT;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET @id = NULL;
SET _parent = @id;
SET _id = -1;
IF @id IS NULL THEN
RETURN NULL;
END IF;
LOOP
SELECT MIN(id)
INTO @id
FROM t_hierarchy
WHERE parent = _parent
AND id > _id;
IF @id IS NOT NULL OR _parent = @start_with THEN
SET @level = @level + 1;
RETURN @id;
END IF;
SET @level := @level - 1;
SELECT id, parent
INTO _id, _parent
FROM t_hierarchy
WHERE id = _parent;
END LOOP;
END
и использовать ее в таком запросе:
SELECT hi.*
FROM (
SELECT hierarchy_connect_by_parent_eq_prior_id(id) AS id, @level AS level
FROM (
SELECT @start_with := 0,
@id := @start_with,
@level := 0
) vars, t_hierarchy
WHERE @id IS NOT NULL
) ho
JOIN t_hierarchy hi
ON hi.id = ho.id
Это, конечно, MySQL , но это очень быстро.
Если вы хотите, чтобы это было переносимо между PostgreSQL и MySQL , вы можете использовать вклад PostgreSQL для CONNECT BY и обернуть запрос в хранимую процедуру с тем же именем для обе системы.
Вообще-то я сам это сделал! Я использовал модель вложенных наборов для представления иерархических данных в реляционной базе данных.
Управление иерархическими данными в MySQL было для меня чистым золотом. Вложенные наборы - вторая модель, описанная в этой статье.
У вас есть выбор между моделями смежности и вложенными моделями множеств. Статья Управление иерархическими данными в MySQL является хорошим введением.
Для теоретического обсуждения см. Trees and Hierarchies Целко.
Довольно просто реализовать список нитей, если ваша база данных поддерживает оконные функции. Все, что вам нужно, это рекурсивная ссылка в таблице целевой базы данных, например:
create Tablename (
RecordID integer not null default 0 auto_increment,
ParentID integer default null references RecordID,
...
)
Затем вы можете использовать рекурсивное общее табличное выражение для отображения многопоточного представления. Пример доступен здесь .
Фактически, это должен быть баланс между чтением и записью.
Если вы в порядке с обновлением группы строк при каждой вставке, тогда вложенный набор (или эквивалент) даст вам легкое и быстрое чтение.
В остальном, простой FK для родительского элемента даст вам сверхпростую вставку, но вполне может стать кошмаром для извлечения.
Я думаю, что я ' d пойти с вложенными наборами, но будьте осторожны с ожидаемым объемом данных и шаблонами использования (обновление нескольких, может быть, большого количества строк в двух индексированных столбцах (для левой и правой информации) для каждой вставки может быть проблемой в какой-то момент) .