Предположим, у нас есть большой набор статистических данных для записи; например, 20-30 INTстолбцов. Лучше хранить весь набор в одной таблице, поскольку все они принадлежат записи ИЛИ создают другую таблицу, связанную с отношением один к одному.
Преимущество первого состоит в том, чтобы избежать JOINи иметь быстрый доступ ко всем статистическим данным для соответствующей записи.
Преимущество последнего заключается в поддержании чистоты колонны. Первый столбец интенсивно читается, а второй интенсивно записывается. Конечно, я думаю, что это не оказывает существенного влияния на производительность, так как я использую InnoDB с блокировкой на уровне строк.
В общем, я хочу знать, полезно ли разделять разные наборы данных для одной записи?
Ответы:
Если это соответствует правилам нормализации, то отношения 1: 1 могут быть нормализованы (по определению!). Другими словами, в отношениях 1: 1 нет ничего, что делало бы невозможным их подчинение нормальным формам.
Чтобы ответить на ваш вопрос о практичности отношений 1: 1, бывают случаи, когда это совершенно полезная конструкция, например, когда у вас есть подтипы с различными предикатами (столбцами).
Причины, по которым вы будете использовать отношения 1: 1, зависят от вашей точки зрения. Администраторы баз данных склонны думать обо всем как о решении по производительности. Разработчики данных и программисты склонны думать, что эти решения ориентированы на дизайн или модель. На самом деле, между этими точками зрения много общего. Это зависит от ваших перспектив и приоритетов. Вот несколько примеров мотивации отношений 1: 1:
У вас есть подмножество очень широких столбцов, и вы хотите физически разделить их в своем хранилище по соображениям производительности.
У вас есть подмножество столбцов, которые не читаются или не обновляются часто, и вы хотите отделить их от часто используемых столбцов по соображениям производительности.
У вас есть некоторые столбцы, которые являются необязательными в целом, но они обязательны, когда вы знаете, что запись имеет определенный тип.
У вас есть несколько столбцов, которые логически связаны друг с другом для подтипа, и вы хотите смоделировать их так, чтобы они соответствовали объектной модели вашего кода.
У вас есть несколько столбцов, которые могут применяться только к некоторым подтипам (ы) супертипа сущности, и вы хотите, чтобы ваша схема обеспечивала отсутствие этих данных для других подтипов.
У вас есть несколько столбцов, которые принадлежат сущности, но вам нужно защитить эти конкретные столбцы, используя более строгие правила доступа (например, зарплата в таблице сотрудников).
Как видите, иногда драйвер - это производительность, иногда - чистота модели или просто желание в полной мере воспользоваться правилами декларативной схемы.
источник
You have some subset of columns that are very wide and you want to segregate them physically in your storage for performance reasons.Как их разделение улучшает производительность (при условии, что к столбцам всегда обращаются каждый раз, когда главная таблица)?Основными причинами, по которым вы используете однозначное сопоставление для разбиения большой таблицы на две, являются, например, соображения производительности:
a) Таблица содержит двоичные данные / данные clob / blob в часто используемой таблице, что снижает производительность, поскольку большие столбцы обрабатываются по-разному.
б) В таблице есть много столбцов, к которым обращаются различные запросы, следовательно, производительность снижается, поэтому вы бы переместили связанные столбцы в отдельную таблицу, чтобы повысить производительность доступа
Однако наличие множества целочисленных столбцов не оправдывает дополнительных усилий по разбивке таблицы на отдельные таблицы и необходимости запрашивать их.
источник