Отношение 1 к 1 на таблицах БД пахнет?

Question

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

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

Есть ли что-то, что я должен остерегаться, когда я делаю это? Это просто плохой выбор?

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

Редактировать: Я буду обосновывать мысли кандидатов не-сущности немного дальше. Эта информация вводится нашей базой пользователей. Они не знают / заботятся друг о друге. Поэтому вполне возможно, что один и тот же пользователь отправит одно и то же «имя ProjectManager» или что-то еще, что на данном этапе не будет нарушать никаких ограничений. В дальнейшем мы должны определить, хотим ли мы сопоставлять записи от отдельных пользователей. Если бы я дал этим вещам свой собственный ключ, они бы росли с той же скоростью, что и основная таблица - потому что они по сути являются частью одной сущности. Ни у кого нет выбора пользователя из списка доступных «менеджеров проектов».

Итак, учитывая вышесказанное, я не думаю, что они являются сущностями. Но, возможно, нет - если у вас есть дальнейшие мысли, пожалуйста, напишите.

Answer 1

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

Я подозреваю, что здесь происходит что-то еще. В приведенном вами примере - PmFirstName - может показаться, что должен быть один pm_id, относящийся к таблице ProjectManagers или Employees. Вы уверены, что ни одна из этих групп на самом деле не является кандидатами в юридические лица?

Answer 2

Я использую отношения 1 к 1 для наследственных конструкций.

Например, все облигации имеют некоторую базовую информацию, такую ​​как CUSIP, Coupon, DatedDate и MaturityDate. Это все идет в основной таблице.

Теперь каждый тип облигации (Казначейство, Корпоративный, Муни, Агентство и т. Д.) Также имеет свой собственный набор уникальных столбцов.

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

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

Создайте таблицу персон, в этом нуждается каждая база данных. Затем в таблице вашего проекта есть столбец с именем PMKey, который указывает на таблицу person.

Answer 3

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

Мне нравится тег запахов.

Answer 4

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

Таким образом, «Менеджер проектов» может быть 1: 1 для всех проектов в настоящее время, но имеет смысл, что позже вы захотите, чтобы у менеджера проекта было более одного проекта. Так что наличие дополнительного стола - это хорошо.

Если у вас есть PrimaryFirstName, PrimaryLastName, PrimaryPhone, SecondaryFirstName, SecondaryLastName, SEcondaryPhone

Вы можете просто иметь таблицу «Персона» с FirstName, LastName, Phone

Тогда вашей исходной таблице нужны только столбцы «PrimaryId» и «SecondaryId», чтобы заменить 6 ранее имеющихся у вас столбцов.

Кроме того, с помощью SQL вы можете разделить файловые группы и таблицы по физическим местам. Таким образом, у вас может быть таблица POST и таблица COMMENT, которые имеют отношение 1: 1, но таблица COMMENT находится в другой файловой группе и на другом физическом диске с большим объемом памяти.

1: 1 не всегда пахнет. Если это не имеет цели.

Answer 5

Почему вы чувствуете, что группа полей не является кандидатами в сущности? Если их нет, зачем пытаться идентифицировать их по префиксу?

Либо отбросьте префиксы, либо извлеките их в свою таблицу.