Jaki jest właściwy sposób korzystania z istniejących pól?

13

Jestem początkującym Drupalem. Nie jestem pewien co do dodawania pól do typów treści.

Przypadek 1: Załóżmy, że mam trzy typy zawartości Book, Articlei White Paper. Stworzyłem Authorssłownictwo, które zawiera listę wszystkich autorów.

  1. Teraz, czy powinienem utworzyć pole „Napisane przez” (termin dla autorów) dla każdego typu zawartości, czy utworzyć pole dla jednego typu zawartości i używać go w innych typach treści?

  2. Jakie są zalety / wady obu metod?

  3. Co się stanie, jeśli usunę pole ponownie wykorzystane z jednego typu zawartości? Czy jest usuwany we wszystkich innych?

Przypadek 2: Śledzę typy zawartości: (z określonymi wymaganiami pola)

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

Co powinienem zrobić? Czy powinienem utworzyć jedno pole dla jednego typu zawartości i użyć go dla wszystkich innych typów treści, czy też utworzyć pole dla każdego typu zawartości?

Pomóż mi jasno zrozumieć, kiedy i jak właściwie ponownie wykorzystać istniejące pola.

pazury
źródło

Odpowiedzi:

8

Czy powinienem utworzyć pole „Napisane przez” (termin dla autorów) dla każdego typu zawartości, czy utworzyć pole dla jednego typu zawartości i używać go w innych typach treści?

Jeśli chcesz zebrać te same informacje dla różnych typów treści, powinieneś użyć jednego pola. Twoje pole „Napisane przez” brzmi jak idealny przypadek do tego. Jeśli masz różnych słowników dla swoich autorów, powiedz „Autor książki”, „Autor artykułu” itp., Chcesz (i musisz) użyć osobnych pól dla każdego z nich.

Jakie są zalety / wady obu metod?

Jedną z zalet jest to, że można wyszukiwać wszystkie typy treści według jednego pola. Jeśli więc chcesz wyświetlić całą zawartość napisaną przez jednego autora, a nawet całą zawartość napisaną przez wszystkich autorów, łatwo będzie utworzyć widok, aby to zrobić. Ale to jest użyteczne, jeśli go potrzebujesz, oczywiście. Przypuszczam, że głównym punktem jest to, że przypadek użycia samego pola faktycznie dyktuje względne zalety / wady każdej z metod.

Ponadto za każdym razem, gdy tworzysz pole, tworzysz dwie tabele bazy danych (jedną dla danych bieżących, drugą dla danych rewizji). Istnieją, powiedzmy, „mieszane” odczucia co do tego, czy ta metoda przechowywania jest najlepszym pomysłem z punktu widzenia wydajności, a niektórzy ludzie wolą ograniczyć liczbę tabel. Po dołączeniu istniejącego pola do innego typu zawartości dla wszystkich z nich używana jest ta sama tabela bazy danych, więc pole zostaje zaznaczone. Ponownie jednak ma to sens tylko wtedy, gdy dane można oddzielić.

Co się stanie, jeśli usunę pole ponownie wykorzystane z jednego typu zawartości? Czy jest usuwany we wszystkich innych?

Pole zostanie usunięte dopiero po odłączeniu od wszystkich typów treści. Dane należące do typu zawartości, z którego odłączono pole, zostaną przeniesione do usuniętej tabeli danych i usunięte podczas uruchomień cron.

Przejdź do przypadku 2 i po prostu zadaj sobie to pytanie ...

Pamiętając o tym, że możesz mieć różne etykiety dla instancji każdego typu zawartości tego samego pola, czy dostarczy ci dostatecznej wizualnej (lub opartej na danych) wskazówki, aby poinformować Cię o różnicach między danymi?

Jeśli tak, użyj pojedynczego pola daty, aby uzyskać korzyści wymienione powyżej. Jeśli nie, to bardziej sensowne jest, aby projekt danych miał oddzielne pola.

Wszystko sprowadza się do tego, co jest odpowiednie dla twojej konkretnej strony, ale mam nadzieję, że powyższe da ci jakiś sposób na postęp.

Clive
źródło
Nie zrozumiałem tego: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?
pazury
4
Chciałem tylko powiedzieć, że wybór należy do Ciebie na podstawie tego, co musisz zrobić z danymi - biorąc pod uwagę datę publikacji i prezentacji, czy ma to dla Ciebie znaczenie, jeśli zostaną one rozdzielone? Czy potrzebujesz filtrować treści według tej daty? Czy da ci niechciane wyniki, jeśli użyjesz jednego pola i uzyskasz dane dla wszystkich typów treści podczas filtrowania na tym polu? To są pytania, które możesz sobie zadać. To naprawdę kwestia projektowania danych, system encji / pól Drupala jest tylko warstwą abstrakcji. Czy projektując to poza Drupalem, umieściłbyś te dane w tej samej tabeli?
Clive