Нормализуются ли отношения один-к-одному?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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