Упрощение базы данных с полиморфными отношениями «многие ко многим», если в одной модели несколько таких отношений.Например, пользовательская модель может иметь полиморфные отношения с таблицами user_types, user_roles, user_statuses.Каждая из этих таблиц вполне может иметь одинаковую структуру, но в обычных отношениях «многие ко многим» со сводными таблицами для включения типов, ролей и состояний потребуется семь таблиц.Со сложной базой данных, такой как та, над которой я работаю, эта проблема быстро распространяется на сотни таблиц.Так как многие люди испытывают трудности в понимании этой проблемы, я включил грубую очень упрощенную схему ниже.В нем вы увидите, что все четыре модели на правой стороне имеют идентичные структуры.Мне это кажется совершенно ненужным, не говоря уже о повторении сводных таблиц. 
Я новичок в Laravel, поэтому я могу упустить очевидное.Во всем, что мне удалось найти о полиморфном Laravel, многие-многие отношения имеют дело с только одиночными такими отношениями в любой модели.Наиболее распространенным примером является ситуация taggable.В этом случае такие модели, как Post, Article и Review, могут иметь одно и только одно отношение к тегируемой модели , хотя каждая из них может иметь несколько тегов .Я думаю, что полностью понимаю это, и это не соответствует ситуации, о которой я говорю.
То, о чем я говорю, - это случай, когда модель программного обеспечения может иметь полиморфное отношение многие ко многим к рубрикам.модель для этапов разработки (альфа, бета, релиз-кандидат и т. д.) и для типов программного обеспечения (текстовый редактор, обмен сообщениями, управление базой данных и т. д.).В этом случае модель Рубрики должна была бы охватить «тип» взаимосвязи (этап разработки программного обеспечения или тип программного обеспечения) в дополнение к модели.
ItПохоже, что это достаточно распространенная проблема, поэтому должен быть какой-то способ сделать это.
Я надеюсь, что кто-то сможет предложить решение, которое упрощает обычные отношения «многие ко многим» стаблица для каждого отдельного аспекта - даже если все такие таблицы, вероятно, будут иметь идентичные структуры - вместе с таблицей сводных / соединительных линий для каждой такой таблицы.