将用户的 ID 存储在表中以创建所有权是错误的吗?
本文关键字:所有权 创建 错误 ID 用户 存储 | 更新日期: 2023-09-27 18:34:56
我有一个简单的事件模型,需要由一次使用拥有。我想做的只是将用户的 ID 作为外键存储在事件表中。然后,在查找时,我将查询该用户拥有的所有事件。简单的东西。
问题是我是 ASP.NET MVC和实体框架的新手,因此,这似乎并不容易。或者更确切地说,似乎有一种更开明的做事方式,当我试图将信息拼凑在一起时,我认为这超出了我目前的技能水平。
如果我走"简单"的方式,只是将用户的ID存储为字符串,我会搬起石头砸自己的脚吗?如果是这样,我真的很感激指出一些推荐的文章或视频来描述这个概念以及如何做到这一点。
我认为你的问题很模糊,但我也认为我明白你在问什么。 您似乎在询问是否应该在用户表和事件表之间创建关系,或者只是将用户 ID 存储在事件表中而不建立关系。
在短时间内,是的,您将以多种方式"搬起石头砸自己的脚"。 首先,在相关实体之间使用外键可以强制数据库的完整性。 这意味着您不能将事件绑定到不存在的用户。 其次,SQL 使用这些外键来更好地索引和查询表。 最后,您将失去实体框架的许多功能,例如能够执行以下操作:
var user = db.Users.First(x=>x.Id == userId);
var userName = user.Name;
var events = user.Events.ToList();
在此示例中,我只需引用一次我的 DataContext,即可访问该对象的任何属性或相关实体。 当然,这是双向的。
var event = db.Events.First(x=>x.Id == eventId);
var eventOwner = event.User;
话虽如此,本文应该会给你一些非常好的指导,让你先做关系和代码。 使用您的示例,它应该像下面一样简单:
public partial class User{
public User(){
this.Events = new HashSet<Event>();
}
public Guid UserId {get;set;}
public string Name {get;set;}
//...other properties as needed
public virtual ICollection<Event> Events {get;set;}
}
public partial class Event{
public int EventId {get;set;}
public Guid UserId {get;set;}
//...other properties
public virtual User User {get;set;}
}
至于将某些内容存储为实际上是 GUID 的字符串,外键将不允许您映射到不同数据类型的列。 它们要么都需要是varchar,要么都需要是Guid(SQL中的唯一标识符(。 与 GUID 保持一致,比随机字符集更好的索引。