Qual é a maneira correta de usar os campos existentes?

Sou iniciante em Drupal. Estou um pouco confuso sobre a adição de campos aos tipos de conteúdo.

Caso 1: suponha que eu tenha três tipos de conteúdo Book, Article& White Paper. Eu criei um Authorsvocabulário que contém uma lista de todos os autores.

Agora, devo criar o campo "Escrito por" (termo-referência para autores) para cada tipo de conteúdo ou criar o campo para um tipo de conteúdo e usá-lo em outros tipos de conteúdo?
Quais são as vantagens / desvantagens de ambos os métodos?
O que acontece se eu excluir um campo reutilizado de um tipo de conteúdo? Ele é excluído em todos os outros?

Caso 2: segui tipos de conteúdo: (com requisitos de campo especificados)

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

O que devo fazer? Devo criar um único campo para um tipo de conteúdo e usá-lo para todos os outros tipos de conteúdo ou criar um campo para cada tipo de conteúdo?

Ajude-me a entender claramente quando e como reutilizar adequadamente os campos existentes.

entities nodes

— garras
fonte

Devo criar o campo "Escrito por" (referência a autores) para cada tipo de conteúdo ou criar o campo para um tipo de conteúdo e usá-lo em outros tipos de conteúdo?

Se você precisar coletar as mesmas informações para diferentes tipos de conteúdo, use um único campo. Seu campo "Escrito por" parece o caso perfeito para isso. Se você possui vocabulários diferentes para seus autores, diga "Autor do livro", "Autor do artigo" etc., você deseja (e precisa) usar campos separados para cada um.

Quais são as vantagens / desvantagens de ambos os métodos?

Uma vantagem é que você pode consultar todos os tipos de conteúdo por um campo. Portanto, se você deseja visualizar todo o conteúdo escrito por um único autor, ou mesmo todo o conteúdo escrito por todos os autores, será fácil criar uma visualização para fazer isso. Mas isso só é útil se você precisar, obviamente. Suponho que o ponto principal é que o caso de uso do próprio campo dite as vantagens / desvantagens relativas de qualquer método.

Além disso, sempre que você cria um campo, cria duas tabelas de banco de dados (uma para dados atuais e outra para dados de revisão). Há, digamos, sentimentos "confusos" sobre se esse método de armazenamento é a melhor ideia do ponto de vista do desempenho, e algumas pessoas preferem manter o número de tabelas baixo. Quando você anexa um campo existente a outro tipo de conteúdo, a mesma tabela de banco de dados é usada para todos eles, para que a caixa seja marcada. Novamente, porém, isso só faz sentido quando seus dados podem ser separados.

O que acontece se eu excluir um campo reutilizado de um tipo de conteúdo? Ele é excluído em todos os outros?

O campo será excluído apenas depois de desanexado de todos os tipos de conteúdo. Os dados que pertencem ao tipo de conteúdo do qual você desanexou o campo serão movidos para uma tabela de dados excluídos e eliminados durante as execuções do cron.

Para o caso 2, e pergunte a si mesmo isso ...

Tendo em mente que você pode ter rótulos diferentes para a instância de cada tipo de conteúdo do mesmo campo, isso fornecerá uma sugestão visual (ou baseada em dados) para informar as diferenças entre os dados?

Nesse caso, use um único campo de data para obter as vantagens mencionadas acima. Caso contrário, faz mais sentido para o seu design de dados ter campos separados.

Tudo se resume ao que é apropriado para o seu site em particular, mas espero que o exposto acima lhe dê algum tipo de caminho a seguir.

— Clive
fonte

Eu não entendi isso:

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?

— garras

Eu apenas quis dizer que depende de você escolher com base no que você precisa fazer com os seus dados - tomando a data de publicação e apresentação como exemplos, importa para você se eles são separados? Você precisa filtrar o conteúdo com base nessa data? Isso fornecerá resultados indesejados se você usar um único campo e obter dados para todos os tipos de conteúdo ao filtrar nesse campo? Esse é o tipo de pergunta que você deve fazer. É realmente uma questão de design de dados, o sistema de entidade / campo do Drupal é apenas a camada de abstração. Se você projetar isso fora do Drupal, você colocaria esses dados na mesma tabela?

— Clive