Referência de coleção e entidade de campo

Como a coleta de campo é uma vantagem? Você pode fazer o mesmo com um novo tipo de conteúdo apontando para o pai com uma Referência de entidade.

Talvez alguém possa quebrar algumas situações em que cada uma seria melhor.

Diga para Tarefa -> Arquivos, a coleção de campos seria melhor ou um novo tipo de conteúdo com uma Referência de entidade?

Digamos que para cada arquivo você precisou de mais alguns dados sobre esse arquivo, soa como um plano para um novo tipo com uma Referência de entidade, mas você pode incorporar uma coleção de campos dentro de uma coleção de campos.

Gosto de como o Drupal tem muitas maneiras de fazer as mesmas coisas, mas não consigo descobrir muito sobre quão diferentes ou semelhantes são essas duas soluções.

Talvez alguém possa ajudar a explicar?

Esta é uma pergunta que eu me proponho ao enfrentar novos projetos, referência de coleção de campos vs entidade + entidade personalizada ou, se a estrutura é simples, coleção de campos vs campo personalizado com várias colunas de banco de dados / campo múltiplo . Aqui está a minha opinião com base na minha experiência .

Multifield é um ótimo conceito, seria uma versão "leve" da coleção de campos. Em vez de criar uma estrutura de entidade com relacionamentos, abrange os casos de uso simples sem criar a entidade. No entanto, existem vários problemas , como a integração incompleta dos recursos, a linguagem não multilíngue, etc (por isso, se você planeja usar isso, as contribuições provavelmente serão bem-vindas).

O Field Collection é uma ótima solução se você estiver criando um site que pode ser feito apenas com alguns ajustes aqui e ali, pois fornece aos construtores de sites uma ferramenta poderosa para criar estruturas complexas sem se preocupar muito com os elementos internos. Basicamente, criará uma entidade que se relaciona com a entidade "host" pelos IDs, permitindo adicionar campos a ela e tudo mais. As desvantagens viriam no conhecimento dos elementos internos da coleção Field que você precisa para executar operações complexas, como gerenciar uma coleção Field com uma referência de entidade ou migrar dados. Como é uma ferramenta genérica, seria bastante complicado ir um passo além.

Outra opção que você tem lá é usar o ECK com referência de entidade, mas minha experiência com isso até agora foi um desastre, acho muito mais fácil criar o tipo de entidade por código sem o auxiliar.

É uma questão do que você precisa e qual é o melhor ajuste para o seu projeto. Se você tiver tempo e os desenvolvedores para criar tipos de entidades que se relacionam com seu modelo de dados por meio da Referência de Entidades, terá mais controle sobre o que está acontecendo com suas estruturas de dados, mas você também é o "responsável" por isso.

Depois de testar um tempo com todas as soluções descritas acima, na minha equipe sempre buscamos os tipos de entidade + ER, mas posso ver que, para pequenos projetos, sem migração de dados ou uma configuração complicada do i18n, o Field Collection é apenas a maneira mais rápida de ir.

Realmente depende dos dados inseridos nos campos e do uso que você deseja fazer com eles.

Se você deseja usar a coleção de campos, certifique-se de que você pode, seja qual for o seu escopo, desde visualizações normais, tradução, indexação de solr etc.

Se você deseja reutilizar as informações adicionadas a uma coleção de campos, será melhor usar um tipo de conteúdo ou uma entidade personalizada. Exemplo: um curso escolar possui 5 tópicos. Um tópico contém 3 campos: título, horas e nível. Se você deseja reutilizar tópicos em vários cursos da escola, escolha um Tipo de conteúdo / Entidade personalizada e use a referência da entidade.

Eles devem ser aproximadamente equivalentes em desempenho, mas a coleção de campos usa a API de entidade e não requer a criação de um tipo de conteúdo personalizado.