Правильное создание модели данных сущности

Question

Я довольно новичок в инфраструктуре сущности и хочу реализовать ее наилучшим образом. Я хотел бы знать, можно ли реализовать идеи, которые я могу реализовать, и если они являются лучшими практиками.

Модель 1

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

Model 1 entity diagram

Модель 2

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

Спасибо за вашу помощь

Model 2 entity diagram

======= Добавлено 16/12/2013 ==============

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

Теперь, когда я пытаюсь добавить стипендиат, например, он справедливо жалуется, что

«Инструкция INSERT заявление противоречит ограничению внешнего ключа„FK_HonoraryMemberLookup“, который я предполагаю, означает, что он пытается чтобы добавить поиск для двух других типов пользователей и не может из-за нулевых значений.

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

Еще раз спасибо

Answer 1

Я бы рекомендовал вам использовать наследование типа Table-Per-Type для достижения того, что вы хотите сделать. Модель будет выглядеть следующим образом, с Lookup объект помечается как Аннотация

Вот несколько примеров кода, которые могли бы использовать эту модель:

class Program 
{ 
    static void Main(string[] args) 
    { 
     using (var container = new UserModelContainer()) 
     { 
      var user = new User 
         { 
          FirstName = "Joe", 
          Surname = "Coder" 
         }; 

      var address = new Address 
          { 
           AddressLine1 = "123 Any Street", 
           AddressLine2 = "Apt 2A", 
           City = "Anytown", 
           StateProvince = "CA", 
           PostalCode = "12345", 
           Country = "United States", 
           IsPublic = false 
          }; 

      user.Lookups.Add(address); 

      container.SaveChanges(); 
     } 

     using (var container = new UserModelContainer()) 
     { 
      foreach (var user in container.Users) 
      { 
       Console.WriteLine("Name: {0} {1}", user.FirstName, user.Surname); 

       foreach (var address in user.Lookups.OfType<Address>()) 
       { 
        Console.WriteLine(address.AddressLine1); 
        Console.WriteLine(address.AddressLine2); 
        Console.WriteLine(address.City); 
        Console.WriteLine(address.StateProvince); 
        Console.WriteLine(address.PostalCode); 
        Console.WriteLine(address.Country); 
        Console.WriteLine("Address is {0}", address.IsPublic ? "Public" : "Private"); 
       } 
      } 
     } 
    } 
} 

Answer 2

Возможно, вы захотите взглянуть на database normalization. Нормализация вашей модели поможет вам избежать хранения одного и того же фрагмента данных несколько раз (может привести к несогласованности) и уменьшить сложность.

Похоже, вы просто хотите связать набор заказов с пользователем и набор адресов для пользователя. Для этого я бы пошел с чем-то вроде модели 2, но без какой-либо таблицы Lookup (напрямую подключая Адреса и Заказы к таблице пользователя).

Единственное, что содержит таблица Lookup, которая дает основание для существования, это флаг IsPublic. Для чего его используют? Если Lookups - это вещи, которые пользователь может создавать, сохранять и обычно знать как thing, тогда таблица Lookup может быть оправдана, и я бы использовал модель 2. Если таблица поиска существует только для облегчения создания запроса, я бы скорее пропустите его, чтобы максимально упростить модель базы данных.

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