Нормализованы ли отношения один к одному?

Question

Считайте, что у нас есть большой набор статистических данных для записи; например, 20-30 INT колонны Лучше ли держать весь набор в одной таблице, так как все они принадлежат записи или создают другую таблицу, связанную с отношениями один к одному.

Преимущество первого состоит в том, чтобы избежать JOIN и иметь быстрый доступ ко всем статистическим данным для соответствующей записи.

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

В целом я хочу знать, полезно ли это для разделения различных наборов данных для одной записи?

Answer 1

Если он вписывается в правила нормализации, то отношения 1: 1 могут быть нормализованы (по определению!) - Другими словами, нет ничего о отношениях 1: 1, что делает им невозможным подчиняться нормальным формам.

Чтобы ответить на ваш вопрос о практичности отношений 1: 1, бывают случаи, когда это совершенно полезная конструкция, например, когда у вас есть подтипы с различными предикатами (столбцы).

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

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

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

• У вас есть некоторые столбцы, которые являются необязательными в целом, но они обязательны, когда вы знаете, что запись имеет определенный тип.

• У вас есть несколько столбцов, которые логически принадлежат друг другу для подтипа, и вы хотите моделировать их, чтобы хорошо соответствовать модели объекта вашего кода.

• У вас есть несколько столбцов, которые могут применяться только к некоторым подтипам (-ам) супертипа сущности, и вы хотите, чтобы ваша схема обеспечила отсутствие этих данных для других подтипов.

• У вас есть некоторые столбцы, которые принадлежат к организации, но вам необходимо защитить эти конкретные столбцы, используя более ограничительные правила доступа (например, зарплата в таблице работников).

Таким образом, вы можете видеть, что иногда драйвер - это производительность, иногда это чистота модели или просто желание в полной мере воспользоваться правилами декларативной схемы.

Answer 2

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

а) Таблица имеет бинарные/клобные данные/капля в часто доступной таблице, следовательно, замедляя производительность, поскольку с большими столбцами обрабатываются по -разному.

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

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