Qual è il modo corretto di utilizzare i campi esistenti?

Sono un principiante di Drupal. Sono un po 'confuso sull'aggiunta di campi ai tipi di contenuto.

Caso 1: Supponiamo che io abbia tre tipi di contenuto Book, Articlee White Paper. Ho creato un Authorsvocabolario che contiene un elenco di tutti gli autori.

Ora, dovrei creare il campo "Scritto da" (termine-riferimento agli autori) per ogni tipo di contenuto o creare il campo per un tipo di contenuto e usarlo in altri tipi di contenuto?
Quali sono i vantaggi / gli svantaggi di entrambi i metodi?
Cosa succede se cancello un campo riutilizzato da un tipo di contenuto? Viene eliminato in tutti gli altri?

Caso 2: ho seguito i tipi di contenuto: (con i requisiti di campo specificati)

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

Cosa dovrei fare? Devo creare un singolo campo per un tipo di contenuto e usarlo per tutti gli altri tipi di contenuto o creare un campo per ciascun tipo di contenuto?

Aiutami a capire chiaramente quando e come riutilizzare in modo appropriato i campi esistenti.

entities nodes

— artigli
fonte

Devo creare il campo "Scritto da" (termine-riferimento agli autori) per ogni tipo di contenuto o creare il campo per un tipo di contenuto e utilizzarlo in altri tipi di contenuto?

Se è necessario raccogliere le stesse informazioni per diversi tipi di contenuto, è necessario utilizzare un singolo campo. Il tuo campo "Scritto da" sembra il caso perfetto per quello. Se hai avuto vocabolari diversi per i tuoi autori, dì "Autore del libro", "Autore dell'articolo", ecc., Vorresti (e dovresti) usare campi separati per ciascuno.

Quali sono i vantaggi / gli svantaggi di entrambi i metodi?

Un vantaggio è che è possibile eseguire una query su tutti i tipi di contenuto in un solo campo. Quindi, se ti trovi a voler visualizzare tutti i contenuti scritti da un singolo autore, o anche tutti i contenuti scritti da tutti gli autori, sarà facile creare una vista per farlo. Ma è utile solo se ne hai bisogno, ovviamente. Suppongo che il punto principale sia che il caso d'uso del campo stesso determinerà effettivamente i vantaggi / gli svantaggi relativi di entrambi i metodi.

Inoltre, ogni volta che si crea un campo, si creano due tabelle di database (una per i dati correnti, una per i dati di revisione). Ci sono, diciamo, sentimenti "contrastanti" sul fatto che questo metodo di archiviazione sia la migliore idea dal punto di vista delle prestazioni e alcune persone preferiscono mantenere basso il numero di tabelle. Quando si collega un campo esistente a un altro tipo di contenuto, viene utilizzata la stessa tabella del database per tutti, in modo che la casella venga spuntata. Ancora una volta, questo ha senso solo quando i tuoi dati possono essere separati.

Cosa succede se cancello un campo riutilizzato da un tipo di contenuto? Viene eliminato in tutti gli altri?

Il campo verrà eliminato solo dopo essere stato staccato da tutti i tipi di contenuto. I dati che appartengono al tipo di contenuto da cui è stato staccato il campo verranno spostati in una tabella di dati eliminati ed eliminati durante le esecuzioni cron.

Passiamo al caso 2 e chiediti solo questo ...

Tenendo presente che è possibile avere etichette diverse per ogni istanza del tipo di contenuto dello stesso campo, questo ti darà abbastanza di un segnale visivo (o guidato dai dati) per farti conoscere le differenze tra i dati?

In tal caso, utilizzare un unico campo data per ottenere i vantaggi sopra menzionati. In caso contrario, ha più senso la progettazione dei dati per avere campi separati.

Tutto si riduce a ciò che è appropriato per il tuo particolare sito Web, ma spero che quanto sopra ti darà una sorta di via da seguire.

— Clive
fonte

Non l'ho capito:

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?

— artigli l'

Intendevo solo che spetta a te scegliere in base a ciò che devi fare con i tuoi dati - prendendo la data di pubblicazione e presentazione come esempi, ti importa se sono separati? Devi filtrare i contenuti in base a quella data? Fornirà risultati indesiderati se si utilizza un singolo campo e si ottengono dati per tutti i tipi di contenuto quando si filtra su quel campo? Queste sono le domande da porsi. È davvero un problema di progettazione dei dati, il sistema di entità / campo di Drupal è solo il livello di astrazione. Se progettassi questo al di fuori di Drupal, inseriresti quei dati nella stessa tabella?

— Clive