Должен ли я повторно использовать существующие поля Drupal?

Иногда мы можем дать очень четкий совет: «Сделай это!» или "Не делай этого!"

Это не будет одним из тех постов в блоге.

Drupal дает вам возможность повторно использовать поля. Если у вас есть поле «Изображение», вы можете использовать его для каждого типа контента на вашем сайте. Однако не всегда ясно, является ли повторное использование полей хорошей идеей. Иногда это так, иногда это не так.

Вот обзор преимуществ и недостатков, которые следует учитывать перед повторным использованием полей Drupal.

Общие советы по повторному использованию полей

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

Документация Drupal.org официально рекомендует не использовать поля повторно:

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

Однако в последние годы этот совет стал более тонким, и Drupal официально заявляет, что в этом есть как преимущества, так и недостатки.

В документации пользовательского интерфейса Drupal Field есть подробный раздел «Повторное использование полей»:

Есть две основные причины повторного использования полей. Во-первых, повторное использование полей может сэкономить ваше время по сравнению с определением новых полей. Во-вторых, повторное использование полей также позволяет отображать, фильтровать, группировать и сортировать контент по полям разных типов контента. Например, дополнительный модуль Views позволяет создавать списки и таблицы содержимого. Таким образом, если вы используете одно и то же поле для нескольких типов контента, вы можете создать представление, содержащее все эти типы контента вместе, отображающее это поле, отсортированное по этому полю и/или отфильтрованное по этому полю. Есть одна основная причина не использовать поле повторно: разные разрешения. Например, вам могут понадобиться разные роли пользователей, чтобы иметь разные уровни доступа к полю, в зависимости от типа контента, к которому оно было добавлено. Это может быть сложно, если вы повторно используете поле.

Преимущество: повторное использование полей может упростить

Да, прирост скорости может быть, но экономия времени очень маленькая. Более убедительным преимуществом является то, что повторное использование полей иногда может упростить администрирование сайта. Веб-инициатива красиво резюмирует это:

Повторное использование полей также может уменьшить сложность системы. Вместо того, чтобы создавать и поддерживать 10 разных полей, администраторы Drupal поддерживают только два поля и их документацию. Администраторам базы данных нужно только улучшить производительность двух дополнительных таблиц. ПОЦЕЛУЙ всегда хороший принцип.

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

Преимущество: некоторый контент хорошо работает с повторно используемыми полями.

Снова вернемся к документации пользовательского интерфейса Drupal Field:

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

Один автор комментариев к документации Drupal.org говорит то же самое о представлениях. Они отмечают, что представления могут комбинировать контент сложными способами. Таким образом, если у вас есть несколько разных типов контента с разными полями даты, представления могут объединять их в одно представление. Однако они также отмечают, что представления не так сложны в сортировке. Таким образом, если у вас есть несколько разных типов контента с разными полями даты, представлениям будет сложно отсортировать контент по всем этим разным полям даты.

Недостаток: повторно используемые поля негибкие.

Брэндон Уильямс в Твиттере прекрасно резюмировал это:

сначала это хорошая идея, но через несколько недель требования меняются, в итоге вы все равно создаете отдельные

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

Недостаток: повторно используемые поля затрудняют экспорт или миграцию данных.

Повторное использование полей может стать проблемой, когда вам нужно экспортировать данные или когда вам нужно перейти на новую версию Drupal или другую платформу.

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

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

Преимущество или недостаток? Представление

Документация Drupal описывает одно возможное преимущество повторного использования полей:

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

В этой ветке на Stack Overflow очень актуально обсуждается производительность. Он включает в себя этот комментарий:

Однако настоящей проблемой является количество полей, которые у вас есть. Потому что в настоящее время в Drupal 7 полная конфигурация всех полей, независимо от того, загружены они или нет, извлекается из кеша при каждом отдельном запросе. Я видел сайты с более чем 250 полями, где загрузка и десериализация конфигурации поля занимает 13 МБ+ памяти».

Таким образом, повторное использование полей может дать небольшое улучшение производительности, позволив нам иметь меньшее общее количество полей.

Однако эти небольшие улучшения могут быть потеряны в другом месте. Это снова от Web Initiative:

[поля] дополнительная сложность системы Drupal. При создании нового поля определение поля добавляется в таблицу классов полей, а конфигурация поля добавляется в таблицу экземпляров поля; тем временем в базу данных Drupal добавляется новая таблица для хранения данных поля. Таблицы базы данных усложняют систему. Кроме того, запросы узлов будут вызывать выражения JOINexpressions таблиц для данных полей. Несколько JOIN повлияют на производительность базы данных, поскольку MySQL плохо отвечает на запросы с несколькими JOIN таблиц, если они не настроены должным образом.

Резюме

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