Когда использовать список (текст) или таксономию?

12

Это может быть глупый вопрос, но мне любопытно, какая выгода от использования поля множественного выбора списка (текста) над справочным полем таксономического термина. Похоже, что они оба выполняют примерно одинаковую функцию предоставления заранее заданных вариантов множественного выбора, но таксономия имеет дополнительное преимущество, заключающееся в том, что вы можете добавлять термины после записи содержимого в базу данных.

Так есть ли какое-нибудь хорошее руководство для того, чтобы использовать один или другой? (И особенно, когда список (текст) имеет больше смысла, чем ссылка на термин таксономии?).

7 taxonomy-terms entities

— сойка
источник

2

Я пытаюсь представить таксономию как «способ структурирования данных по категориям» (включая древовидные структуры), а в списке «Предложение нескольких определенных вариантов», когда организация не важна. В случае сомнений я выбираю таксономию, так как интеграция в просмотр с помощью представлений выполняется быстро.

— Джейк Двеб

1

Единственное, что не может сделать select / text - это структурировать иерархию данных; Только таксономия предлагает деревья.

— Рене

Об этом есть статья на eosrei.net/articles/2013/12/… .

— колан

10

Структура и динамика являются ключевыми словами IMO для выбора таксономии. Недавно мне задали этот вопрос, когда я отмечал компании географическими регионами. Моим первым выбором была подготовка таксономии со списком регионов. Вскоре это оказалось чрезмерным осложнением. Регионы почти никогда не меняют своих названий и почти никогда не меняют свою структуру / родителей. Поэтому я отказался от таксономии и решил использовать плоский список (текст). Теперь также намного проще маневрировать регионами в представлении. Так что - если ваш список статичен и ровен - перейдите к списку.

— Артур
источник

3

Ну, есть одна очевидная вещь, которая пришла мне в голову - я бы сказал, использовать таксономию, когда вы хотите, чтобы теги имели свои собственные страницы, заполненные пользовательскими полями, изображениями, отображаемыми в различных режимах (полный, тизер и т. Д.)

— Артур

принимая это, потому что это дало некоторые плюсы и минусы. Точка зрения Патрика Кенни о производительности тоже важна.

— Джей

8

Таксономия имеет проблемы с производительностью, поскольку она масштабируется, потому что запросы SQL становятся длиннее; Если вы используете фильтры представлений, выбор списков будет быстрее, чем таксономия.

— Патрик Кенни
источник

Как правило, это правда, но с опытом вы узнаете, что вы должны использовать поиск SOLR для масштабирования представлений с фильтрами, так что тогда это не имеет большого значения.

— Марко Блазекович

7

Ключевые различия, которые я узнал, были:

Вы хотите, чтобы пользователи добавляли в список значений, а не только администраторы сайта, или добавление в список будет полупостоянной потребностью даже администраторов сайта?
хотите ли вы использовать это значение в качестве самоорганизующейся части контента (как предложено выше @Artur, создавая страницы всего контента, который разделяет этот термин, с разными макетами, например, страница продукта: показать всю одежду XL; или новости, показать все виды спорта)
Являются ли данные вообще иерархическими? (например: подкатегории, в которых вы хотите иногда захватить родительскую категорию или дочерние категории в других)

Если нет на все вышеперечисленное, используйте select / text. Если да, используйте термины таксономии. В моем опыте вы обычно используете select / text. Это всегда кажется неправильным, но обычно это правильно.

— Renee
источник

0

Безусловным победителем, на мой взгляд, стал бы термин таксономия, большая мощность, небольшие недостатки.

— Марко Блазекович
источник