¿Cuál es la forma correcta de usar los campos existentes?

Soy un principiante de Drupal. Estoy un poco confundido acerca de agregar campos a los tipos de contenido.

Caso 1: supongamos que tengo tres tipos de contenido Book, Article& White Paper. Creé Authorsvocabulario que contiene la lista de todos los autores.

Ahora, ¿debo crear el campo "Escrito por" (referencia de término a Autores) para cada tipo de contenido o crear el campo para un tipo de contenido y usarlo en otros tipos de contenido?
¿Cuáles son las ventajas / desventajas de cualquiera de los métodos?
¿Qué sucede si elimino un campo reutilizado de un tipo de contenido? ¿Se elimina en todos los demás?

Caso 2: he seguido los siguientes tipos de contenido: (con requisitos de campo específicos)

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

¿Qué tengo que hacer? ¿Debo crear un solo campo para un tipo de contenido y usarlo para todos los demás tipos de contenido o crear un campo para cada tipo de contenido?

Ayúdame a comprender claramente cuándo y cómo reutilizar adecuadamente los campos existentes.

entities nodes

— garras
fuente

¿Debo crear el campo "Escrito por" (referencia de término a Autores) para cada tipo de contenido o crear el campo para un tipo de contenido y usarlo en otros tipos de contenido?

Si necesita recopilar la misma información para diferentes tipos de contenido, debe usar un solo campo. Su campo "Escrito por" suena como el caso perfecto para eso. Si tenía vocabularios diferentes para sus autores, diga "Autor del libro", "Autor del artículo", etc., desearía (y necesitaría) usar campos separados para cada uno.

¿Cuáles son las ventajas / desventajas de cualquiera de los métodos?

Una ventaja es que puede consultar todos los tipos de contenido por un solo campo. Por lo tanto, si desea ver todo el contenido escrito por un solo autor, o incluso todo el contenido escrito por todos los autores, será fácil crear una vista para hacerlo. Pero eso solo es útil si lo necesitas, obviamente. Supongo que el punto principal es que el caso de uso del campo en sí mismo dictará las ventajas / desventajas relativas de cualquiera de los métodos.

Además, cada vez que crea un campo, crea dos tablas de base de datos (una para datos actuales y otra para datos de revisión). Hay, digamos, sentimientos "mixtos" sobre si este método de almacenamiento es la mejor idea desde el punto de vista del rendimiento, y algunas personas prefieren mantener baja la cantidad de mesas. Cuando adjunta un campo existente a otro tipo de contenido, se utiliza la misma tabla de base de datos para todos ellos, de modo que se marca esa casilla. Una vez más, esto solo tiene sentido cuando sus datos se pueden separar.

¿Qué sucede si elimino un campo reutilizado de un tipo de contenido? ¿Se elimina en todos los demás?

El campo solo se eliminará una vez que se haya separado de todos los tipos de contenido. Los datos que pertenecen al tipo de contenido del que separó el campo se moverán a una tabla de datos eliminados y se purgarán durante las ejecuciones cron.

En el caso 2, y solo pregúntate, pregúntate esto ...

Teniendo en cuenta que puede tener diferentes etiquetas para la instancia de cada tipo de contenido del mismo campo, ¿eso le dará suficiente señal visual (o basada en datos) para que sepa las diferencias entre los datos?

Si es así, use un solo campo de fecha para obtener las ventajas mencionadas anteriormente. Si no, entonces tiene más sentido para su diseño de datos tener campos separados.

Todo se reduce a lo que es apropiado para su sitio web en particular, pero con suerte lo anterior le dará algún tipo de camino a seguir.

— Clive
fuente

No entendí esto:

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

Solo quería decir que depende de usted elegir según lo que necesite hacer con sus datos, tomando la fecha de publicación y presentación como ejemplos, ¿le importa si se separan? ¿Necesita filtrar contenido en función de esa fecha? ¿Le dará resultados no deseados si usa un solo campo y obtiene datos para todos los tipos de contenido al filtrar en ese campo? Esas son las preguntas que debes hacerte. Es realmente un problema de diseño de datos, el sistema de entidad / campo de Drupal es solo la capa de abstracción. Si diseña esto fuera de Drupal, ¿colocaría esos datos en la misma tabla?

— Clive