当多个用户都扮演不同的角色时，我应该如何将它们存储在数据库中？

Question

我正在创建一个具有四个用户的属性查看应用程序：Office Manager，Property Advisor，卖方和买方。我希望所有人都登录一次，但我不知道应该从哪里开始。

我需要具有它们的ID，因为我正在将它们用于应用程序中的不同功能。例如，sellerId将链接到属性。一个BuyerId和PropertyAdvisorId将链接到一个约会。我想知道最好的方法是什么？

Answer 1

您是说您确实有四个用户或四种类型的用户吗？我认为是后者。继承的用户如果你的类型有很多共同点，如姓名，地址等，这将是最好有一个基本类型User，和几个派生类型：OfficeManager，PropertyAdvisor，等。每个User都有零个或多个Rights，每个Right被确认为零个或多个Users：一个简单的多对多关系。数据库不能很好地处理继承的概念，您必须使用一种变通方法来实现它。实体框架知道几种实现继承的策略。这里描述了其中几个在您的情况下，最好使用“每类型表”：您将有一个Users表，并为派生类分别设置了一个Sellers表，一个Buyers表等。这些表中的每个表都具有该表的外键User。abstract class User{&nbsp; &nbsp; public int Id {get; set;}&nbsp; &nbsp; // every User has zero or more rights (many-to-many)&nbsp; &nbsp; public virtual ICollection<Right> Rights {get; set;}&nbsp; &nbsp; ... // other properties}class Seller : User{&nbsp; &nbsp; // inherit primary key Id from base class&nbsp; &nbsp; ... // seller properties}class Buyer : User{&nbsp; &nbsp; // inherit primary key Id from base class&nbsp; &nbsp; ... // buyer properties}class Rights{&nbsp; &nbsp; public int Id {get; set;}&nbsp; &nbsp; // every right is acknowledged to zero or more Users (many-to-many)&nbsp; &nbsp; public virtual ICollection<User> Users {get; set;}&nbsp; &nbsp; ... // properties that handle the rights.}您需要告诉Entity Framework，您想要为用户/买方/卖方提供单独的表格。这可以使用属性来完成。我更喜欢使用流利的API：public MyDbContext : DbContext{&nbsp; &nbsp; // The tables:&nbsp; &nbsp; public DbSet<Right> Rights {get; set;}&nbsp; &nbsp; public DbSet<User> Users {get; set;&nbsp; &nbsp; public DbSet<Seller> Sellers {get; set;}&nbsp; &nbsp; public DbSet<Buyer> Buyers {get; set;}&nbsp; &nbsp; ...&nbsp; &nbsp; protected override void OnModelCreating(DbModelBuilder modelBuilder)&nbsp; &nbsp; {&nbsp; &nbsp; &nbsp; &nbsp; // Buyers and Sellers are in separate tables:&nbsp; &nbsp; &nbsp; &nbsp; modelBuilder.Entity<Buyer>().ToTable("Buyers");&nbsp; &nbsp; &nbsp; &nbsp; modelBuilder.Entity<Seller>().ToTable("Sellers");&nbsp; &nbsp; &nbsp; &nbsp; // if you want you could name the User and Right tables&nbsp; &nbsp; &nbsp; &nbsp; // but that is not needed. Entity Framework already knows&nbsp; &nbsp; &nbsp; &nbsp; // they should be in separate tables&nbsp; &nbsp; &nbsp; &nbsp; modelBuilder.Entity<User>().ToTable("Users");&nbsp; &nbsp; }}这将导致一个Users表，一个Rights表，一个用于Users和之间的多对多关系的联结表Rights，以及每个用户派生类一个单独的表，每个表都具有该Users表的外键。您是否注意到我将User类抽象化了？这是为了防止用户DbContext添加User。我们不知道Users作为对象，我们只知道Buyers和Sellers（etc）关于表每种类型的好处是，如果你想查询的项目，所有的Users都有，就像一个名称/地址，只有一个查询表，无接缝是需要的，即使其中的一些Users是Buyers有的Sellers。另外，如果仅查询Buyer属性，则仅访问“买方”表。缺点是，如果要查询“买方”属性及其“用户”属性，则需要“用户”与“买方”表之间的联接。每种类型的表是否最适合您取决于您最常执行的查询类型。阅读所有描述的三种方法组成方法另一种方法不是使用继承，而是使用组合。这样，您的DbSet类将更好地描述您的表。其缺点是，它似乎有点怪你的DbContext的用户：Buyersdont't HAVE Users，他们Users，不是吗？与其说卖方和买方是特殊类型的用户（继承），不如 说他们有用户UserInformation（组成）。这是一对一的关系。每个人UserInformation都有零个或多个权利（一对多）。组成将导致与每个类型的表相同的表。唯一的区别是您的类更好地表示了您的表，但代价是您的类表示了您的直觉Sellers并且Buyers减少了Users的使用。class UserInformation{&nbsp; &nbsp; &nbsp;public int Id {get; set;}&nbsp; &nbsp; &nbsp;public string FirstName {get; set;}&nbsp; &nbsp; &nbsp;public string MiddleName {get; set;}&nbsp; &nbsp; &nbsp;...&nbsp; &nbsp; &nbsp;// every UserInformation has zero or more rights: (many-to-many)&nbsp; &nbsp; &nbsp;public virtual ICollection<Right> Rights {get; set;}}class Buyer{&nbsp; &nbsp; public int Id {get; set;}&nbsp; &nbsp; // Every Buyer has some UserInformation using foreign key (one-to-one)&nbsp; &nbsp; public int UserInformationId {get; set;}&nbsp; &nbsp; public virtual UserInformation UserInformation {get; set;}&nbsp; &nbsp; ...}class Seller{&nbsp; &nbsp; public int Id {get; set;}&nbsp; &nbsp; // Every Seller has some UserInformation using foreign key (one-to-one)&nbsp; &nbsp; public int UserInformationId {get; set;}&nbsp; &nbsp; public virtual UserInformation UserInformation {get; set;}&nbsp; &nbsp; ...}这将导致一个UserInformations表，一个Rights表，一个用于UserInformations和之间的多对多关系的联结表Rights，以及每个用户派生类一个单独的表，每个表都具有该Users表的外键。完全相同的表。选择是您自己的：如果要向您的用户隐藏内部数据库结构，请使用继承；如果DbContext要让您的数据库设计渗透到DbContext用户，请使用组合。