От 1 до 1 отношений на db столах запах?

Question

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

Например, у всех облигаций есть основная информация, такая как CUSIP, Купон, Датированная дата и Срок погашения. Все это входит в основную таблицу.

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

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

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

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

Answer 5

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

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

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

Вы могли бы просто иметь "Person" стол с FirstName, LastName, Телефон

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

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

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