Сколько соединений возможно на практике

этот вопрос может быть более подходящим для программистов.клиент StackExchange. Если да, то просьба мигрировать.

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

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

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

6
database feasibility join sql

4 ответов

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

базы данных поставляется с различными функциями, чтобы сделать вашу жизнь проще:

  • вы можете создавать представления для наиболее часто используемых запросов (хотя это не единственный случай использования для представления);
  • некоторые РСУБД обеспечивает Общие Табличные Выражения (CTE), которые позволяют использовать именованные подзапросы, а также рекурсивные запросы;
  • некоторые СУБД предоставляют языки расширения (например, PL / SQL или PL / pgSQL), что позволяет разрабатывать собственные функции, чтобы скрыть сложность схемы и использовать только вызовы API для работы ваши данные.

некоторое время назад был как-то связан вопрос о как работает оператор SQL, содержащий mutiple joins? возможно, стоит также изучить его.

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

5

нормализация баз данных сама по себе является формой искусства.
Если вы правильно структурируете свои соединения, вы будете захватывать только необходимые столбцы.
Это должно быть намного быстрее, чтобы запустить запрос с миллионами записей с несколькими таблицами и просто присоединиться к необходимым полям, то это было бы, если у вас есть одна или две таблицы со всеми записями. Во втором примере вы извлекаете все данные, и сортировка по ним будет кошмаром кодирования.
MySQL очень хорош только получение запрошенных данных.
Только потому, что запрос длинный, не означает, что он медленнее.
Я видел запросы более 20 строк кода, которые были очень быстро.

Имейте веру в запрос, который вы пишете, и если вы не пишете тестовый сценарий, попробуйте сами.

5

полностью нормализованная модель данных имеет большую стоимость в производительности, но более устойчива к изменениям. Модель данных flat as a dime, настроенная для одного запроса, будет работать намного лучше, но вам придется заплатить цену, когда спецификации изменятся.

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

3

чтобы решить Ваш вопрос ответ:

http://en.wikipedia.org/wiki/Database_normalization

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

1