Odbiór pola a odniesienie jednostki

W jaki sposób zbieranie w terenie jest zaletą? Możesz zrobić to samo z nowym typem zawartości wskazującym na element nadrzędny za pomocą odwołania do encji.

Może ktoś może rozwiązać niektóre sytuacje, w których każda byłaby lepsza.

Powiedzmy dla zadania -> Pliki, czy zbieranie pól byłoby lepsze czy nowy typ zawartości z odniesieniem do jednostki?

Powiedz, że dla każdego pliku potrzebujesz więcej innych danych o tym pliku, brzmi to jak plan nowego typu z odniesieniem do jednostki, ale możesz osadzić kolekcję pól w kolekcji pól.

Lubię, jak Drupal ma wiele sposobów robienia tych samych rzeczy, ale nie mogę znaleźć wiele na temat tego, jak różne są te dwa rozwiązania.

Może ktoś może pomóc wyjaśnić?

To pytanie zadaję sobie w obliczu nowych projektów, Field Collection vs Entity Reference + encja niestandardowa lub jeśli struktura jest prosta, Field Collection vs niestandardowe pole z kilkoma kolumnami db / Multifield . Oto moja opinia oparta na moich doświadczeniach .

Multifield to świetna koncepcja, byłaby to „lekka” wersja zbioru pól, zamiast tworzenia struktury encji z relacjami, obejmuje proste przypadki użycia bez tworzenia encji. Ma jednak wiele problemów , takich jak niepełna integracja funkcji, niezbyt wielojęzyczna itp. (Więc jeśli planujesz to wykorzystać, prawdopodobnie będziesz mile widziany).

Field Collection to świetne rozwiązanie, jeśli tworzysz witrynę, którą można wykonać za pomocą kilku drobnych poprawek tu i tam, daje ona twórcom witryn potężne narzędzie do tworzenia złożonych struktur bez martwienia się o elementy wewnętrzne. Zasadniczo utworzy encję powiązaną z encją „hosta” za pomocą identyfikatorów, umożliwiając dodanie do niej pól i wszystkiego. Wady wynikałyby ze znajomości elementów wewnętrznych kolekcji Field, że należy wykonywać złożone operacje, takie jak zarządzanie kolekcją Field z referencją encji lub migrowanie danych. Ponieważ jest to ogólne narzędzie, przejście o krok dalej byłoby dość skomplikowane.

Inną dostępną opcją jest korzystanie z ECK z Entity Reference, ale moje dotychczasowe doświadczenia z tą katastrofą były dla mnie znacznie łatwiejsze. Łatwiej jest stworzyć typ encji według kodu bez pomocnika.

Jest to kwestia tego, czego potrzebujesz i co najlepiej pasuje do twojego projektu, jeśli masz czas i programiści, aby stworzyć typy jednostek, które odnoszą się do twojego modelu danych poprzez Entity Reference, będziesz mieć większą kontrolę nad tym, co się dzieje struktury danych, ale to Ty też jesteś za to „odpowiedzialny”.

Po pewnym czasie testowania wszystkich rozwiązań opisanych powyżej, w moim zespole zawsze wybieramy typy encji + ER, ale widzę, że w przypadku małych projektów, bez migracji danych lub skomplikowanej konfiguracji i18n, Field Collection jest po prostu najszybszym sposobem na udać się.

To zależy od danych, które wprowadzasz w polach i od tego, jak chcesz je wykorzystać.

Jeśli chcesz korzystać z Field Collection, upewnij się, że możesz do wszystkiego, co mieści się w twoim zakresie, od normalnych widoków, do tłumaczenia, indeksowania solr itp.

Jeśli chcesz ponownie wykorzystać informacje dodane do zbioru pól, lepiej będzie użyć typu zawartości lub encji niestandardowej. Przykład: Kurs szkolny obejmuje 5 tematów. Tematy zawierają 3 pola: tytuł, godziny i poziom. Jeśli zamierzasz ponownie używać tematów na kilku kursach szkolnych, wybierz Typ treści / Niestandardowa jednostka i użyj referencji do jednostki.

Powinny one być w przybliżeniu równoważne pod względem wydajności, ale kolekcja pól używa interfejsu API jednostki i nie wymaga tworzenia niestandardowego typu treści.