Полиморфная ассоциация - это всегда плохо?

Question

Я понимаю концепцию полиморфных ассоциаций и то, как их можно избежать, используя шаблоны наследования таблицы, как объясняется Martin Fowler.

Учитывая, что у вас есть база данных, состоящая из большого количества таблиц, содержащих много типов объектов (1000+), и предположим, что вам нужно добавить что-то вроде комментария или примечания к любому из сохраненных объектов в базе данных.

Используя Полиморфную Ассоциацию, вы должны создать таблицу типов объектов, которые могут иметь комментарии или заметки, а также таблицу, содержащую идентификатор типа и идентификатор объекта в его таблице и комментарий. Вы, очевидно, не получаете ссылочную целостность с этим.

Использование решений на основе наследования, с которыми я столкнулся, предложением в этой ситуации было бы создание таблицы, которая действовала бы как «основной» класс всех сущностей в базе данных, чтобы вы могли создать внешний ключ между ID в этой таблице и EntityID в таблице комментариев.

Это означает, что каждая строка в каждой таблице нуждается в строке в этой таблице, и вам нужно будет вставить запись в эту таблицу, чтобы сгенерировать идентификатор для объекта (я знаю, что вы можете использовать уникальный идентификатор, но у него есть свой собственный подводные камни). Для меня это похоже на то, что узкое место появлялось вокруг этой таблицы.

Другой альтернативой может быть создание таблицы между каждой таблицей сущностей и таблицей комментариев. Однако, если вам нужны комментарии, заметки, теги и т. Д., Вы в конечном итоге увеличиваете количество таблиц в базе данных на огромную сумму.

Кто-нибудь пытался сделать что-то подобное в реальном мире, и вы обнаружили, что использование Полиморфной ассоциации было лучшим решением, несмотря на отсутствие ссылочной целостности в базе данных?

Answer 1

Все это зависит от ваших критериев для определения того, какое решение лучше.

Более простым решением является создание единой таблицы полиморфных ассоциаций. Это будет изначально быстрее для программиста. Он вписывается в хорошо документированные шаблоны; особенно в некоторых структурах типов MVC, распространенных сегодня. Тем не менее, это на самом деле более сложное решение, поскольку в настоящее время существует одна таблица, которая охватывает многие концепции. Кроме того, правильность данных не может быть гарантирована, поскольку ссылочная целостность не может быть реализована.

Более простым решением является создание единой таблицы для каждой взаимосвязи, так что существует единственная таблица, которая включает в себя одну концепцию. Это позволяет использовать ссылочную целостность, чтобы гарантировать правильность и качество данных и быстрее для сопровождающего программного обеспечения при оценке влияния изменений на систему. Тем не менее, это более сложное решение, так как изначально требуется создание большего количества таблиц.

Теперь вам нужно сделать субъективный выбор относительно того, хотите ли вы выбрать более простое или простое решение.