В каких случаях удобно использовать поле EntityID вместо дополнительных таблиц?

Question

[Александр Евгеньевич]

Здравствуйте.
Для примера:
есть таблица Notification (уведомления). Уведомления у нас могут быть системными (System), могут быть уведомления связанные с работой над сущностями БД. Соответственно, при получении уведомления нам необходимо узнать его тип, и получить данные, отталкиваясь от типа.
Далее вопрос, как будет более правильным : создавать дополнительные таблицы со связями OneToOne ?
Notifications:

• - id
  
• - user_id
  
• - created_at
  
• - active
  
• - type (SYSTEM_TYPE, POST_TYPE, COMMENT_TYPE ...)
  

NotificationSystem:

• - id (one-to-one)
  
• - data
  
• - system_type
  

NotificationPost:

• - id (one-to-one)
  
• - post_id
  

NotificationComments:

• - id (one-to-one)
  
• - comment_id
  

-----
Либо создавать одну таблицу для всех случаев с разными столбцами:
Notifications:

• - id
  
• - user_id
  
• - created_at
  
• - active
  
• - type (SYSTEM_TYPE, POST_TYPE, COMMENT_TYPE ...)
  
• - system_type
  
• - post_id
  
• - comment_id
  
• ...
  

------
Либо использовать для дополнительных типов столбец EntityId:
Notifications:

• - id
  
• - user_id
  
• - created_at
  
• - active
  
• - type (SYSTEM_TYPE, POST_TYPE, COMMENT_TYPE ...)
  
• - system_type
  
• - entity_id ("Post23", "Post24", "Comment12", "Comment13" ...)
  

Хотелось бы узнать ваше мнение.
*надеюсь все правильно написал

Answer 1

[Сергей Протько]

вам нужно наследование (table inheritance) и разные типы объектов для разных типов нотификаций. Это если брать "обычно".

p.s. при работе с доктриной проще оперировать сущностями и взаимоотношением оных а не таблицами. Это domain-centric штука, а не data-centric.

Comments

[Александр Евгеньевич]

но ведь Inheritance есть как SingleTable и есть Join. В конечном счете это будут таблицы в БД, вот мне и интересно для каких случаев, какой вариант лучше, хотя бы в общих чертах.

[Сергей Протько]

Александр Евгеньевич: джойны удобно когда у нас много разных полей, сингл тэйбл инхеритенс банально производительнее.

[Александр Евгеньевич]

Сергей Протько: вопросец такой, а вы не пробовали использовать Entity Inheritance, но без поля с дискриминатором ?

[Сергей Протько]

Александр Евгеньевич: без него работать как бы не будет.

[Александр Евгеньевич]

Сергей Протько: просто хорошо бы подошло к oneToOne связям, чтобы постоянно не работать с родительским объектом через сеттер и геттер. Как я понял, это нужно писать свое наследование, грубо говоря.

[Сергей Протько]

Александр Евгеньевич: что вы понимаете под "своим наследованием"? Ради бога не городите свои велосипеды без надобности (у вас ее нет).

Почитайте документацию к доктрине. Там описаны все кейсы, что зачем и почему и когда что хорошо.

[Александр Евгеньевич]

родитель:
Parent
id
common_field_1
common_field_2
...
---
дочерние:
Child1 extends Parent
parent_id
child1_field_1
child1_field_2
....
---
Child2 extends Parent
parent_id
child2_field_1
child2_field_2
....

[Сергей Протько]

Александр Евгеньевич: так и причем тут наследование если у вас обычное дерево?

[Александр Евгеньевич]

Сергей Протько: при наследовании удобно обращаться к свойствам родителя у дочернего класса. нежели так:
$child->getParent()->setCommonField1();
либо через такое:

$parent = new Parent(); 
$parent->setCommonField1(); 
$child = new Child1(); 
$child->setParent($parent);

[Сергей Протько]

Александр Евгеньевич: вот только при этому у вас уже не дерево и другим разработчикам будет не слишком очевидны преимущества подобного.

Наследование нужно только для того, что бы запереть общие вещи в абстрактном классе.