MySQL: много объединений и отношений в одной таблице (теоретический вопрос)

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

No.

Если мы сохраним все это в одной базовой таблице элементов, повлияет ли как-то на производительность создание представлений (собака, кошка, мышь)?

No.

Отдельные таблицы означают, что это принципиально разные вещи — разные атрибуты или разные операции (или оба разные).

Одна и та же таблица означает, что это в основном одно и то же — одни и те же атрибуты и одни и те же операции.

Производительность не является первым соображением.

Смысл — первое соображение.

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

«Собака, кошка, мышь» — все млекопитающие. Один стол.

«Собака, кошка, мышь» — это два хищника и одно всеядное. Две таблицы.

«Собака, кошка, мышь» — это два обычных домашних питомца и один обычный вредитель. Две таблицы.

«Собака, кошка, мышь» — это одно крутое животное и два противных. Две таблицы.

«Собака, кошка, мышь» — это три отдельных вида. Три стола.

Это о смысле.

Попытка построить схему, которая может вместить новые объекты, не проанализированные и не включенные при проектировании базы данных, — это идея, которая снова и снова возникает при обсуждении реляционных баз данных.

В классическом реляционном моделировании данных отношения могут быть разработаны в свете определенных утверждений, которые должны быть высказаны в отношении обсуждаемой вселенной. Эти предложения представляют собой факты, которые пользователи данных могут получить, извлекая данные из базы данных. Базовые отношения утверждаются путем сохранения чего-либо в базе данных. Производные отношения могут быть получены операциями над базовыми отношениями. Когда база данных SQL создается с использованием реляционной модели данных в качестве ориентира, базовые отношения становятся таблицами, а производные отношения — представлениями.

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

На практике за последние 25 лет большинство баз данных было создано на основе анализа, который, как позже выяснилось, был неполным или неверным. Затем базы данных пересматриваются в свете нового и улучшенного анализа, а пересмотренная база данных иногда требует обслуживания кода приложения. Безусловно, реляционная модель и базы данных SQL создавали меньше зависимостей приложений, чем дореляционные базы данных.

Но естественно попытаться придумать общую схему данных, подобную вашей, которая может вместить любой предмет без каких-либо изменений схемы. У такого подхода есть последствия, и они связаны с гораздо большими затратами, чем просто проблемы с производительностью. Для небольших проектов эти расходы вполне управляемы, и в таких случаях может хорошо работать полностью общая схема.

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

Я не могу доказать вам, что такой подход должен привести к катастрофе. Но учиться на чужих ошибках зачастую гораздо полезнее, чем рисковать повторить их.

Конечно, доступ к данным в объединенной таблице всегда БУДЕТ медленнее. Но с правильными индексами это может быть приемлемым замедлением (например, в 2 раза).

Я бы переместил общие элементы, которые вы используете в запросах, в таблицу элементов и оставил в item_data только значения, которые вам нужно отображать, которые не используются в условиях WhERE и JOIN.