Блог

#c# #sql #database #database-design #entity-framework-core

Вопрос:

 public class AppUserModel
    {
        [Key]
        public int AppUserId { get; set; }

        public string UserName { get; set; }

        public int? DesignerId { get; set; }

        public int? ClientId { get; set; }

        public int? WorkroomId { get; set; }  

        ...
    }
 

Комментарии:

1. Вам нужно быть более описательным: какие отношения «много-много» между этими тремя должны представлять?

2. Вы уже проверили таблицу по иерархическому подходу? При таком подходе вы могли бы сохранить всех дизайнеров, клиентов, рабочие комнаты в одной таблице, дифференцированной с помощью дискриминатора. Его реализация осуществляется с помощью общего базового типа. Тогда вы могли бы позволить базовому типу AppUserModel иметь множество отношений между собой и другими пользователями. Взаимосвязь «многие ко многим» будет решена самим ядром entity framework и приведет к созданию новой сводной таблицы. Пусть имя будет AppUserAppUsers, потому что оно связано само с собой.

3. Я выбрал другой подход в начале 2.0 и 3.1. Я создал таблицу, которая в вашей ситуации называлась бы ClientWorkroomDesigners. Что касается ваших трех разных типов, вам понадобится перечисление, чтобы различать ваши типы. Кроме того, я создал таблицы ClientInfo, WorkroomInfo, DesignerInfo для получения дополнительной информации и установил связь «один к одному» между этими пользователями приложений. Проблема заключалась в том, что 2 из 3 навигационных свойств имеют значение null. Несмотря на это, я создал таблицу отношений, которая позволила мне создавать отношения между этими дизайнерами клиентской комнаты

4. Спасибо. Мне просто было интересно, может ли стол иметь много-ко-многим сам по себе. Я попробую использовать подход с таблицей для каждой иерархии.

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

Ответ №1:

Комментарии:

1. OC написал, что рабочие комнаты также являются пользователями приложений All designers, clients, and workrooms are app users and should have a record in AppUsers. , и я мог бы понять, что между дизайнерами и клиентами существуют отношения. А также отношения между дизайнерами и рабочими комнатами. Потому что я предполагаю, что дизайнер может выбирать из разных рабочих комнат, и клиенты не привязаны к рабочим комнатам. Это как говорит учитель today we are in this room . Клиенты следуют за дизайнером, а не за комнатой. Я прав?

2. Если Дизайнер и Клиент должны использовать Рабочую комнату, то таблица WorkroomUsage отношений остается в силе. Если Рабочая комната необязательна, вам понадобится отдельная таблица для описания этих отношений. Лично я не думаю, что у рабочей комнаты должны быть отношения с пользователем приложения, если это не участник приложения, а просто ресурс.

3. Извините — я имел в виду следующее: «Если рабочая комната необязательна, вам понадобится либо отдельный стол, чтобы охватить эти отношения, либо разрешить workroomId находиться null в таблице.

4. Спасибо. Все это очень полезно. Я настроил шаблон таблицы по иерархии в соответствии с этой документацией: docs.microsoft.com/en-us/ef/core/modeling/inheritance Да, рабочие комнаты являются пользователями приложений, потому что они войдут в приложение и получат спецификации дизайна, отправленные дизайнерами. Поэтому дизайнерам нужно много-много с рабочими комнатами и клиентами.