Отношения один к одному. Нужен ли столбец Id для обеих таблиц? - PullRequest
Новая
       18

Отношения один к одному. Нужен ли столбец Id для обеих таблиц?

0 голосов
/ 18 апреля 2020

Давайте рассмотрим таблицы: 

CREATE TABLE [dbo].[User] (
    [Id] INT PRIMARY KEY,
    ...
);

CREATE TABLE [dbo].[UserInfo_1] (
    [Id] INT PRIMARY KEY,
    [UserId] INT,
    ...,
    CONSTRAINT FK_UserId FOREIGN KEY ([UserId]) REFERENCES [dbo].[User] (Id)
);

CREATE TABLE [dbo].[UserInfo_2] (
    [UserId] INT PRIMARY KEY,
    ...,
    CONSTRAINT FK_UserId FOREIGN KEY ([UserId]) REFERENCES [dbo].[User] (Id)
);

Каковы преимущества и недостатки использования FOREIGN KEY для UserInfo_1 and UserInfo_2 таблиц? Также с точки зрения ОРМ.

Ответы [ 2 ]

2 голосов
/ 18 апреля 2020

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

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

второй из User и UserInfo_2 является отношением один к одному. В котором с одним User может быть связан только один UserInfo_2.

С точки зрения производительности, поскольку они проиндексированы, они будут работать относительно одинаково, в зависимости от вашей фильтрации и плана, который был кэширован в плане запроса. хотя у вас могут возникнуть неполадки с планами кэшированных запросов, поскольку EF использует операторы ad-hock, хотя EF запускает память кэшированного плана и обычно рекомендуется отключать ее при использовании EF.

Один-к-одному

Я фанат отношений один-к-одному, особенно в аспекте разработки, управляемой доменом, и при правильной реализации. Если каждая из ваших строк для User будет запрашивать информацию из UserInfo_2, то я теоретически буду хранить их в таблице User. Теперь, если вы знаете, что вы не будете запрашивать эту информацию много или не все Users потребуют столбцы в этой таблице, или если ваша основная таблица достаточно велика, я бы оставил ее как отношение один к одному.

Мне лично нравится использовать систему управления версиями. У меня есть таблицы, которые содержат определенные столбцы, которые обычно обновляются и столбцы, которые почти никогда не обновляются. Те, кого я знаю, обновляют на ежедневной / еженедельной основе. Я собираю их в отношении один к одному с основной таблицей, которые почти никогда не должны обновляться. Но у каждого бизнеса потребности и сценарии разные. Не любой дизайн подходит для всех ситуаций.

Преимущества индексирования

При создании внешнего ключа вы создаете индекс в базе данных. Это позволит вам выполнять более быстрые запросы. Оптимизатор SQL будет использовать индекс, чтобы лучше находить то, что вы ищете. Без индекса ваш план запроса превратится в сканирование таблицы, которое представляет собой построчный поиск. Выполняя поиск по строкам, вы можете серьезно замедлить работу вашей системы по мере роста таблицы.

Если вы решите создать свои таблицы без индекса или в этом случае индекса внешнего ключа, вы можете столкнуться с проблемами в аспекте ORM. Когда вы запрашиваете базу данных у EF, вы вызываете свой DbSet. Если у вас были правильные соединения внешнего ключа с вашими двумя таблицами, EF может использовать .Include, чтобы объединить эти две таблицы в поисках того, что вам нужно. В противном случае вам придется использовать два запроса в базе данных для обеих таблиц.

В проекте, над которым я работал один раз, разработчик сделал это. Он не правильно подключил соединение с внешним ключом между двумя объектами, а затем не понял, почему EF не будет правильно возвращать свои значения, когда он использовал .Include и не очень быстро. Он думал, что это вина Э.Ф., и ему пришлось сделать два запроса, чтобы получить необходимую ему информацию.

1 голос
/ 18 апреля 2020

Well User> UserInfo_1 - это отношение один ко многим, поскольку UserInfo_1.UserID не является ключом. И EF 6 не поддерживает альтернативные ключи. EF Core делает, так что вы можете сделать его ключевым.

Но самый простой дизайн - это всегда свести 1-1 отношения в одну таблицу. В EF Core вы по-прежнему можете иметь основной тип сущности и один или несколько отдельных типов собственных сущностей . Но в базе данных обычно лучше иметь их в одной таблице.

Во-вторых, проще всего иметь обе таблицы с одинаковыми ключевыми столбцами.

...