Raccolta campi vs riferimento entità

In che modo la raccolta sul campo rappresenta un vantaggio? Puoi fare la stessa cosa con un nuovo tipo di contenuto che punta all'elemento principale con un riferimento entità.

Forse qualcuno può abbattere alcune situazioni in cui ognuno sarebbe meglio.

Dire per attività -> File, sarebbe migliore la raccolta dei campi o un nuovo tipo di contenuto con un riferimento di entità?

Supponiamo che per ogni file siano necessari altri dati su quel file, sembra un piano per un nuovo tipo con un riferimento entità, ma è possibile incorporare una raccolta di campi all'interno di una raccolta di campi.

Mi piace come Drupal abbia molti modi di fare le stesse cose, ma non riesco a trovare molto su quanto siano diverse o simili queste due soluzioni.

Forse qualcuno può aiutare a spiegare?

Questa è una domanda che mi pongo di fronte a nuovi progetti, Raccolta campi vs Riferimento entità + entità personalizzata o se la struttura è semplice, Raccolta campi vs campo personalizzato con più colonne db / Campo multiplo . Ecco la mia opinione basata sulla mia esperienza .

Multifield è un grande concetto, sarebbe una versione "leggera" della raccolta di campi, invece di creare una struttura di entità con relazioni, copre i semplici casi d'uso senza creare l'entità. Ha una serie di problemi , tuttavia, come l'integrazione delle funzionalità non completa, non realmente multilingue ecc. (Quindi, se si prevede di utilizzare questo, i contributi saranno probabilmente molto graditi).

Field Collection è un'ottima soluzione se stai realizzando un sito che può essere fatto solo con alcune modifiche qua e là, offre ai costruttori di siti uno strumento potente per creare strutture complesse senza preoccuparsi molto degli interni. Fondamentalmente creerà un'entità che si relaziona con l'entità "host" dagli id, permettendo di aggiungere campi ad essa e tutto. Gli svantaggi risiederebbero nella conoscenza degli interni della raccolta Field che è necessario eseguire operazioni complesse come la gestione di una Collezione Field con un riferimento di entità su di essa o la migrazione dei dati. Essendo uno strumento generico, sarebbe piuttosto complicato andare oltre.

Un'altra opzione che hai lì è usare ECK con Entity Reference, ma la mia esperienza con questo è stata finora un disastro, trovo molto più facile creare il tipo di entità per codice senza l'helper.

È una questione di ciò di cui hai bisogno e qual è la soluzione migliore per il tuo progetto, se hai il tempo e gli sviluppatori per creare tipi di entità che si relazionano con il tuo modello di dati tramite Entity Reference, avrai un maggiore controllo su ciò che sta accadendo con le tue strutture di dati, ma poi anche tu sei il "responsabile".

Dopo aver testato un po 'con tutte le soluzioni sopra descritte, nel mio team cerchiamo sempre i tipi di entità + ER, ma posso vedere che per i piccoli progetti, senza migrazione dei dati o una complicata configurazione i18n, Field Collection è solo il modo più veloce per partire.

Dipende molto dai dati che inserisci nei campi e dall'uso che vuoi farne.

Se vuoi usare Field Collection, assicurati di poter fare tutto ciò che rientra nel tuo ambito di applicazione, dalle visualizzazioni normali, alla traduzione, all'indicizzazione di solr ecc.

Se desideri riutilizzare le informazioni che aggiungi in una raccolta di campi, sarà meglio utilizzare un tipo di contenuto o un'entità personalizzata. Esempio: un corso scolastico ha 5 argomenti. Un argomento contiene 3 campi: titolo, ore e livello. Se hai intenzione di riutilizzare gli argomenti in diversi corsi scolastici, scegli un Tipo di contenuto / Entità personalizzata e usa il riferimento Entità.

Dovrebbero essere approssimativamente equivalenti in termini di prestazioni, ma la raccolta dei campi utilizza l'API Entity e non richiede la creazione di un tipo di contenuto personalizzato.