Коллекция полей против ссылки на сущность

Как сбор полей является преимуществом? Вы можете сделать то же самое с новым типом контента, указывающим на родителя со ссылкой на сущность.

Может быть, кто-то может сломать некоторые ситуации, когда каждая из них будет лучше.

Скажем, Задача -> Файлы, будет ли коллекция полей лучше или новый тип контента с Entity Reference?

Скажем, для каждого файла вам нужно больше других данных об этом файле, звучит как план для нового типа с Entity Reference, но вы можете встроить коллекцию полей в коллекцию полей.

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

Может быть, кто-то может помочь объяснить?

Это вопрос, который я задаю себе, когда сталкиваюсь с новыми проектами, Field Field vs Entity Reference + настраиваемый объект или, если структура проста, Field Collection vs настраиваемое поле с несколькими столбцами db / Multifield . Вот мое мнение, основанное на моем опыте .

Multifield - отличная концепция, это будет «облегченная» версия коллекции полей, вместо создания структуры сущностей со связями, она охватывает простые варианты использования без создания сущности. Однако у него есть ряд проблем , таких как неполная интеграция функций, не совсем многоязычность и т. Д. (Поэтому, если вы планируете использовать это, материалы, вероятно, будут действительно приветствоваться).

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

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

Это вопрос того, что вам нужно, и что лучше всего подходит для вашего проекта: если у вас есть время и разработчики для создания типов сущностей, которые связаны с вашей моделью данных через Entity Reference, вы будете иметь больше контроля над тем, что происходит с ваши структуры данных, но вы также «ответственны» за это.

После некоторого тестирования всех решений, описанных выше, в моей команде мы всегда выбираем типы сущностей + ER, но я вижу, что для небольших проектов, без миграции данных или сложной настройки i18n, Field Collection - это самый быстрый способ идти.

Это действительно зависит от данных, которые вы вводите в поля, и от того, какое использование вы хотите с ними делать.

Если вы хотите использовать Field Collection, убедитесь, что вы можете использовать все, что находится в вашей области: от обычных представлений до перевода, индексации и т. Д.

Если вы хотите повторно использовать информацию, которую вы добавляете в коллекцию полей, будет лучше использовать тип контента или пользовательский объект. Пример: в школьном курсе 5 тем. Тема содержит 3 поля: название, часы и уровень. Если вы собираетесь повторно использовать темы в нескольких школьных курсах, выберите тип контента / пользовательский объект и используйте ссылку на объект.

Они должны быть примерно эквивалентны по производительности, но сбор полей использует API-интерфейс Entity и не требует создания пользовательского типа контента.