Краткий ответ: может быть, в зависимости от того, что вы будете делать.
Длинный ответ: Обычно с точки зрения базы данных / хранилища механизм ключевых слов разбивается на две (группы) таблиц.
Теперь я рассмотрю простейший случай с двумя таблицами, который довольно четко (ИМХО) объяснит явление.
Первая (группа) таблиц - это таблица, в которой хранятся ключевые слова . В этой таблице может быть переменное количество полей, но для нашей цели есть только следующие поля:
- Уникальный идентификатор ключевого слова (первичный ключ таблицы или сокращенно PK)
- Уникальный идентификатор ключевого слова родителя (для гиков: ссылка на родительский PK)
- (только для пользователей) Название ключевого слова (текст, который будет отображаться на экране)
Важное поле здесь - это второе, которое может иметь специальное значение ( 'null' , 0, -1 и т. Д.), Если у указанного ключевого слова нет родителя.
Как можно видеть здесь, когда мы говорим о таблице ключевых слов, нет никакой разницы, если список ключевых слов плоский или иерархический. .
Хорошо, если мы хотим быть пуристами, мы можем утверждать, что программа, которая будет поддерживать только плоские списки ключевых слов, может быть немного быстрее, потому что у нее не будет 2-го поля, но обычно это списки ключевых слов. довольно малы по сравнению с вычислительной мощностью современных компьютеров, поэтому разница будет незначительной в этом отношении.
Но есть вторая таблица - таблица ключевых слов - где все усложняется.
Таблица ссылок на ключевые слова - это таблица, в которой хранятся ссылки между каждым ключевым словом и каждой фотографией, которой присвоен.
В простейшем случае эта таблица имеет следующую структуру:
- Идентификатор ключевого слова (PK ключевого слова из таблицы выше)
- Идентификатор изображения (ПК изображения из таблицы изображений)
Большая проблема с этой таблицей в том, что она очень быстро растет . Для 100 000 фотографий (что представляет собой коллекцию обычного среднего размера), на каждом изображении должно быть только 4-7 ключевых слов (что, где, когда, кто как минимум - также, жанр, техника и т. Д.), Что приводит к увеличению таблицы до 400 000 - 700.000 записей.
Теоретически , как видно из структуры таблицы, нет никакой разницы между использованием плоской или иерархической структуры ключевых слов.
Но практически это может быть разница, потому что на практике разница между теорией и практикой намного больше, чем в теории .
Конкретно, для нашего обсуждения в Lightroom существует опасное поведение, когда одновременно с назначением ключевого слова изображению программа считает, что ему назначены все родительские ключевые слова .
Хорошо, если вы знаете, что делаете, это может быть хорошо (вот почему почти все программы имеют это), но в противном случае он может фактически масштабировать таблицу ключевых слов LOT, которая может вызывать (и вызывать) - в зависимости от того, что вы делаете - проблемы с производительностью.
Следовательно, (в зависимости от вашего оборудования) я советую быть осторожным с иерархией Lightroom. Хотя я думаю, что «плоский» список (даже если лучшее решение в нашем обсуждении) слишком ограничен, я бы сказал, что используйте иерархические ключевые слова, но не делайте дерево слишком глубоким.
Кроме того, я не вижу кардинальности ветви как проблемы (IOW не имеет большого значения для 'Root1', чтобы иметь 100 или 1000 детей), но, как я уже сказал, скорее уровень вложенности.