Как правильно использовать существующие поля?

13

Я начинающий Drupal. Я немного озадачен добавлением полей к типам контента.

Случай 1: Предположим, у меня есть три типа контента Book, Article& White Paper. Я создал Authorsсловарь, который содержит список всех авторов.

  1. Теперь, я должен создать поле «Автор» (ссылка на автора) для каждого типа контента или создать поле для одного типа контента и использовать его в других типах контента?

  2. Каковы преимущества / недостатки обоих методов?

  3. Что произойдет, если я удалю повторно использованное поле из одного типа контента? Это удаляется во всех других?

Случай 2: У меня следующие типы содержимого: (с указанными полевыми требованиями)

+--------------+----------------------+
| Content Type | Field Required       |
+--------------+----------------------+
| Book         | Year of publication  |
+--------------+----------------------+
| Presentation | Date of Presentation |
+--------------+----------------------+
| Article      | Date of Publication  |
+--------------+----------------------+
| Event        | Held On              |
+--------------+----------------------+

Что я должен делать? Должен ли я создать одно поле для одного типа контента и использовать его для всех других типов контента или создать поле для каждого типа контента?

Помогите мне четко понять, когда и как правильно использовать существующие поля.

когти
источник

Ответы:

8

Должен ли я создать поле «Автор» (ссылка на автора) для каждого типа контента или создать поле для одного типа контента и использовать его в других типах контента?

Если вам нужно собрать одну и ту же информацию для разных типов контента, вам следует использовать одно поле. Ваше поле «Автор» звучит как идеальный случай для этого. Если у ваших авторов были разные словари, например, «Автор книги», «Автор статьи» и т. Д., Вы бы хотели (и должны) использовать отдельные поля для каждого из них.

Каковы преимущества / недостатки обоих методов?

Одним из преимуществ является то, что вы можете запрашивать все типы контента по одному полю. Поэтому, если вы захотите просмотреть весь контент, написанный одним автором, или даже весь контент, написанный всеми авторами, вам будет легко создать представление для этого. Но это только полезно, если вам это нужно, очевидно. Я полагаю, что главное в том, что сценарий использования самого поля фактически будет диктовать относительные преимущества / недостатки любого из этих методов.

Кроме того, всякий раз, когда вы создаете поле, вы создаете две таблицы базы данных (одну для текущих данных, одну для данных ревизии). Скажем так, есть «смешанные» чувства по поводу того, является ли этот метод хранения лучшей идеей с точки зрения производительности, и некоторые люди предпочитают уменьшать количество таблиц. Когда вы присоединяете существующее поле к другому типу контента, для всех них используется одна и та же таблица базы данных, поэтому этот флажок ставится. Опять же, это имеет смысл только тогда, когда ваши данные могут быть разделены.

Что произойдет, если я удалю повторно использованное поле из одного типа контента? Это удаляется во всех других?

Поле будет удалено только после того, как оно было отсоединено от всех типов контента. Данные, принадлежащие к типу контента, от которого вы отсоединили поле, будут перемещены в удаленную таблицу данных и удалены во время выполнения cron.

В случае 2, и просто спросите, спросите себя это ...

Помня о том, что у вас могут быть разные метки для каждого экземпляра типа контента в одном и том же поле, даст ли вам достаточно визуального (или управляемого данными) сигнала, чтобы вы знали разницу между данными?

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

Все сводится к тому, что подходит для вашего конкретного сайта, но, надеюсь, вышеизложенное даст вам какой-то путь вперед.

Клайв
источник
Я не понял этого:Keeping in mind that you can have different labels for each content type's instance of the same field, will that give you enough of a visual (or data-led) cue to let you know the differences between the data?
когти
4
Я просто имел в виду, что вы должны выбирать, основываясь на том, что вам нужно делать с вашими данными - принимая дату публикации и презентации в качестве примера, имеет ли значение для вас, если они будут выделены? Вам нужно отфильтровать контент на основе этой даты? Даст ли он нежелательные результаты, если вы используете одно поле и получите данные для всех типов контента при фильтрации по этому полю? Это те вопросы, которые нужно задать себе. Это действительно проблема проектирования данных, система сущностей / полей в Drupal - это просто уровень абстракции. Если вы разрабатываете это вне Drupal, вы бы поместили эти данные в одну таблицу?
Клайв