Связи на примере покемона
Модель "сущность-связь" может быть реализована разными способами. Вопрос в том, какой из них наиболее выгодный? Рассмотрим на примере покемона - бульбазавра.
I, II, III, IV, V и X - поколения игр. В первом поколении у покемонов был атрибут Special, который в следующих поколениях разделили на Sp. Attack и Sp. Defense. "Поколение X" на самом деле не существует, но придумаем его для примера случая, когда атрибуты не только появляются и исчезают, но и меняются.
Каждый атрибут представлен сущностью-числом и связан непосредственно с покемоном. Связь говорит о том, что данное число является конкретным атрибутом (атака, защита, скорость...) данного покемона. Одно число может иметь несколько таких связей, если атрибуты равны. Связь "атрибут-покемон" сама по себе является сущностью. Атрибуты соотносятся с поколениями через связи, прикреплённые к сущности "атрибут-покемон".
[+] Экономия записей и идентификаторов в базе данных.
[-] Если понадобится отредактировать защиту, не трогая атаку, то придётся произвести операцию разделения сущности на две.
[-] Пользователю нужно показывать именно список атрибутов, а не числа, связанные с покемоном - при показе сущности тоже придётся "размножить".
[-] Экономить место в базе данных не слишком нужно, современные базы данных и так архивируют похожие записи.
То же самое, но даже при равенстве чисел разные атрибуты представлены разными сущностями. Одна и та же сущность-число по-прежнему может выражать атрибут в разных поколениях, если он равен. Система становится более логичной, однако нарисовать таблицу из рис. 1 на сайте может быть не так просто, потому что соответствия с поколениями нужно получать через два запроса (запрос на связи; запрос на сущности, на которые указывают связи).
В этой модели атрибуты группируются в наборы, и уже наборы связаны с поколениями.
[+] Удобно показывать статы покемона в разных поколениях, отправляя сущности-набору команду "показать себя".
[-] Если понадобится объединить ячейки с одинаковыми параметрами между несколькими наборами, это может быть непросто. Впрочем, это один из вопросов движка: показ сущностей, учитывающий другие сущности.
Называется буквой, потому что это вариант для любой из моделей выше. В ней связь атрибута и покемона (или набора) звучит не "А - защита Б", а "А - атрибут Б, а само название атрибута подключается через добавочную связь. Это позволяет удобнее ответить на вопрос "найти все атрибуты покемона Б", потому что не придётся сначала искать все связи, дочерние к "А - атрибут Б". Зато это делает более сложным создание списка покемонов по их значению защиты.
[+] Если на сайте будет много разных типов монстров (из "Покемонов", из "Дигимонов", из D&D...), то суммарно у них может быть несколько сотен разных видов числовых атрибутов. Тогда иметь метку с названием логичнее, чем сто типов связей.
Вместо того, чтобы представлять каждый атрибут отдельной сущностью, они представляются общей сущностью с перечислением "Атака 45, Защита 45, Сп.атака 65...".
[+] Страхует от ошибки, когда у покемона могут быть два атрибута скорости.
[-] Механизмы и дополнения, приспособленные для работы с сущностями-числами, не сработают на этой строгой модели. А ведь именно для этого создаётся единообразный движок.
[-] Если на сайте будет много разных типов монстров, то под каждый придётся создавать отдельный формат. Кроме того, может быть сложно выразить монстров с неортодоксальными атрибутами (скажем, с двумя атрибутами скорости).