Quelle est la bonne façon d'utiliser les champs existants?

Je suis un débutant Drupal. Je suis un peu confus quant à l'ajout de champs aux types de contenu.

Cas 1: Supposons que j'ai trois types de contenu Book, Article& White Paper. J'ai créé un Authorsvocabulaire qui contient la liste de tous les auteurs.

Maintenant, dois-je créer un champ "Écrit par" (référence de terme aux auteurs) pour chaque type de contenu ou créer le champ pour un type de contenu et l'utiliser dans d'autres types de contenu?
Quels sont les avantages / inconvénients des deux méthodes?
Que se passe-t-il si je supprime un champ réutilisé d'un type de contenu? Est-il supprimé dans tous les autres?

Cas 2: J'ai suivi les types de contenu: (avec les exigences de champ spécifiées)

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

Que devrais-je faire? Dois-je créer un champ unique pour un type de contenu et l'utiliser pour tous les autres types de contenu ou créer un champ pour chaque type de contenu?

Aidez-moi à comprendre clairement quand et comment réutiliser correctement les champs existants.

entities nodes

— les griffes
source

Dois-je créer un champ «Écrit par» (référence de terme aux auteurs) pour chaque type de contenu ou créer le champ pour un type de contenu et l'utiliser dans d'autres types de contenu?

Si vous devez collecter les mêmes informations pour différents types de contenu, vous devez utiliser un seul champ. Votre champ "Écrit par" semble être le cas parfait pour cela. Si vous aviez des vocabulaires différents pour vos auteurs, par exemple "Auteur de livre", "Auteur d'article", etc., vous voudriez (et auriez besoin) d'utiliser des champs séparés pour chacun.

Quels sont les avantages / inconvénients des deux méthodes?

Un avantage est que vous pouvez interroger tous les types de contenu par le même champ. Donc, si vous souhaitez voir tout le contenu écrit par un seul auteur, ou même tout le contenu écrit par tous les auteurs, il sera facile de créer une vue pour ce faire. Mais cela n'est utile que si vous en avez besoin, évidemment. Je suppose que le point principal est que le cas d'utilisation du champ lui-même dictera en fait les avantages / inconvénients relatifs de l'une ou l'autre méthode.

De plus, chaque fois que vous créez un champ, vous créez deux tables de base de données (une pour les données actuelles, une pour les données de révision). Il y a, dirons-nous, des sentiments «mitigés» quant à savoir si cette méthode de stockage est la meilleure idée du point de vue des performances, et certaines personnes préfèrent limiter le nombre de tables. Lorsque vous associez un champ existant à un autre type de contenu, la même table de base de données est utilisée pour chacun d'eux, de sorte que cette case est cochée. Encore une fois, cela n'a de sens que lorsque vos données peuvent être séparées.

Que se passe-t-il si je supprime un champ réutilisé d'un type de contenu? Est-il supprimé dans tous les autres?

Le champ ne sera supprimé qu'une fois qu'il aura été détaché de tous les types de contenu. Les données appartenant au type de contenu dont vous avez détaché le champ seront déplacées dans une table de données supprimées et purgées lors des exécutions périodiques.

Passons au cas 2, et posez-vous simplement la question suivante:

En gardant à l'esprit que vous pouvez avoir des étiquettes différentes pour chaque instance de type de contenu du même champ, cela vous donnera-t-il suffisamment de repères visuels (ou basés sur des données) pour vous faire connaître les différences entre les données?

Si c'est le cas, utilisez un seul champ de date pour bénéficier des avantages mentionnés ci-dessus. Sinon, il est plus logique pour votre conception de données d'avoir des champs séparés.

Tout se résume à ce qui est approprié pour votre site Web particulier, mais j'espère que ce qui précède vous donnera une sorte de voie à suivre.

— Clive
source

Je n'ai pas compris cela:

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?

— griffes

Je voulais juste dire que c'est à vous de choisir en fonction de ce que vous devez faire avec vos données - en prenant la date de publication et de présentation comme exemples, cela vous importe-t-il de les séparer? Avez-vous besoin de filtrer le contenu en fonction de cette date? Cela vous donnera-t-il des résultats indésirables si vous utilisez un seul champ et obtiendra-t-il des données pour tous les types de contenu lors du filtrage sur ce champ? Voilà le genre de questions à se poser. C'est vraiment un problème de conception de données, le système d'entités / champs de Drupal n'est que la couche d'abstraction. Si vous concevez ceci en dehors de Drupal, mettriez-vous ces données dans le même tableau?

— Clive