Посилання на сутність та систематику


10

Скажімо, у мене є команда, в якій є члени. У мене є тип вмісту для команди та тип контенту для окремих членів команди. Скажімо, є й інші стосунки, наприклад, команди можуть належати до відділів, і є проекти, які можна призначити особам або командам.

Як я це розумію, я можу визначити відносини між цими сутностями двома способами - або посилання суб'єктів господарювання, або використовуючи терміни таксономії. Коли я повинен використовувати один тип над іншим? Краще вибрати лише один метод, або змішати їх?

Мені здається, що таксономія найбільш гнучка, тому що легко будувати дерева, використовуючи типи таксономії, або, наприклад, якщо в команді я тоді вирішив, що хочу створити ієрархію в команді, функціонал вже є (просто перетягніть терміни таксономії в ієрархії), тоді як якщо я використовував посилання на сутність, я не можу придумати простий спосіб зробити це (крім додавання таксономії, що призводить до надмірності).

Здається, що тут є щось, чого я не розумію, але я не впевнений, що це таке!

Будь-яка допомога буде вдячна.


Гаразд, я досяг певного прогресу в розумінні - посилання на суб'єкт господарювання насправді може бути терміном таксономії! тому "Команда B" насправді може бути як Тип вмісту (що містить опис), так і посиланням посилання Суб'єкта на термін "Таксономія" (однойменної). Тоді користувач може бути пов’язаний із терміном Таксономія, а не типом вмісту ...
Джеймс

Думаю, одне, що я досі не розробив, - це різниця між наявністю поля у типі вмісту, що є терміном таксономії, та посиланням на сутність, що посилається на термін таксономії - останній видається як додатковий рівень ускладнення.
Джеймс

Вони досить порівнянні. Незрозуміло, мені подобається використовувати Entity Reference.
alex laughnan

Але якщо ви використовуєте посилання на Entity, все ж є випадки, коли все ж краще використовувати таксономію, чи не так? Так, наприклад, якщо у нас є ієрархія організації, мені здається, що таксономія - це кращий спосіб зробити це.
Джеймс

Відповіді:


21

Ви тут говорите про дві різні концепції. Перше питання пов'язане з тим, коли хочеться впорядкувати вміст у різні категорії або якщо потрібно створити взаємозв'язок між існуючими типами вмісту. Інше питання полягає в тому, якщо при використанні таксономії краще буде використовувати опорне поле таксономії або посилання суб'єкта господарювання.


Щодо першої концепції

Це залежить від вашого випадку використання. Так, як ви згадали, таксономії чудово підходять для побудови ієрархій, але в ідеалі не слід використовувати таксономії, щоб містити фактичний вміст. Причина цього проста - хоча ви можете додавати поля до термінів таксономії, усі ієрархічні рівні в систематиці використовують однакові поля. Якщо взяти приклад із членами різних команд, це може призвести до проблем. Якщо ви хочете зберегти більше інформації про команду чи члена, а не лише ім'я. Якщо, наприклад, ви хочете зберегти інформацію про ім’я, прізвище та біографію члена, і додати ці поля до систематики, вони будуть доступні також на командних умовах. І якщо ви додасте поле для опису команди для команд, вони з’являться для членів команди.

Таксономії найкраще використовувати при організації ієрархічної подібності предметів . Як теги, наприклад:

  • овочевий
    • морква
    • картопля
  • фрукти
    • яблуко
    • банан

Посилання на об'єкти відмінно підходять для встановлення зв’язків між типами вмісту. Приклади включають, коли у вас тип вузла "команда" та тип вузла "член команди", кожен з яких має власні поля. Або тип вузла "пісня", який посилається на "альбом", який сам посилається на "музиканта". У зв'язку з цим посилання на суб'єкти господарювання є більш гнучкими, ніж таксономії, оскільки це дозволяє скласти більш складні відносини. Використовуючи представлення даних, ви також можете використовувати ці відносини. Беручи свій приклад, ви можете створити представлення всіх членів команди, використовуючи посилання на сутність для відносин, і ви могли б відображати будь-яке поле типу типу вмісту команди, а також поля з вузла члена.

Законодавчі поля, що посилаються на вузли, і поля таксономії також є законними. У вашому прикладі з командами і команда, і член можуть бути вузлом, посилаючись один на одного на посилання на сутність. У той же час, департамент може бути системою таксономії з усіма наявними підрозділами.


Щодо другої концепції

Коли DO випустив D7, він постачається з еталонним полем таксономії, яке буде використано при посиланні на таксономії. Відтоді ми побачили випуск модуля Entity API і, отже, посилального модуля сутності, а оскільки терміни та таксономії є сутностями, можна посилатися на них, як на будь-яку іншу сутність. На даний момент вони працюють дуже схоже, і в багатьох випадках не має значення, яким саме ви користуєтесь. Однак є ще деякі внесені модулі, що надають польові формати та віджети, які працюють лише для того чи іншого. Отже, це в основному залежить, якщо вам потрібен такий формат, якщо ви повинні використовувати посилання таксономії чи посилання на сутність.

Оскільки DO замінює поле опорного поля таксономії опорним полем сутності в D8, я вважаю за краще перейти з посилальним полем сутності до посилання на таксономії, а не з полем, поданим модулем таксономії.


2
Яке чудове пояснення! Велике спасибі! Тепер я розумію!
Джеймс
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.