所以,我的数据库现在看起来像:
Comment -> Commentable
Commentable -> News
Commentable -> Files
Commentable -> Photo
这意味着,当我添加新实体(文件或照片)时,我必须添加新的Commentable并将此值插入实体。
这是什么最好的做法?我应该覆盖实体的create function,还是将它放入repository add function?
表的结构看起来像这样,bcz我不需要为每个实体创建自己的注释表。
修改:我的表架构如下:Branko Dimitrijevic帖子中的One table vs multiple tables
当我想首先添加新文件或事件时,我必须生成新的“可注释”行,并且仅在此之后 - 添加与我的实体相关。
所以,我的问题,我必须把这个逻辑或如何在最正确的实践中做到这一点?
THX。
答案 0 :(得分:1)
仔细考虑照片,新闻和文件表的设计。 当我发布第一个Stackoverflow问题时,我正在思考类似的问题:Database design - articles, blog posts, photos, stories。
我意识到文章,照片,视频,文档和BlogPost都共享了一些常见的字段,如作者,发布日期,标题,描述,关键字等。所以我创建了一个超类型/子类型的表层次结构,使用EF的类型继承功能对其进行建模。然后注释只有一个外键,一个超类型的talbe(我将其命名为Publications)。在大多数情况下,这对我来说非常有效。
请注意,如果使用EF的继承:有两种变体:每个类型的表(TPT)和每个表的表(TPH),每个都有问题:
TPT :为公共字段提供超级表,为每个子类型提供单独的数据库表。当您查询超类型时,这会出现性能问题(有时很严重)。解决方法是创建一个视图,将超类型表引用为一个不同的实体(这就是我所做的),但它比你想要的更麻烦
TPH :没有性能问题,但解决方案基本上将层次结构扁平化为一个表。我发现,DBA和数据库纯粹主义者真的不喜欢你这样做。
答案 1 :(得分:0)
你不需要这样做。如果你有正确的模型结构,EF会这样做。
public class Comment
{
public int ID { set;get;}
public string Author { set;get;}
public IEnumrable<CommentContent> CommentContents
}
public class CommentContent
{
public int ID { set;get;}
public string Photo { set;get;}
public string News{ set;get;}
public int CommentID { set;get;}
}
现在让你的模型设置属性(包括子)并执行SaveChanges,EF将负责在子表上设置父ID。
var model=new Comment();
model.Author="Scott";
model.CommentContents.Add(new CommentContent
{ Photo="abc.jpg", News="Some content"});
model.CommentContents.Add(new CommentContent
{ Photo="abc3.jpg", News="Some content2"});
yourDbContext.Comments.Add(model);
yourDbContext.SaveChanges();
答案 2 :(得分:0)
了解您正在尝试实现的目标的“官方”术语可能会有所帮助,因此您可以进行进一步的研究。它是多态关联。请注意,它通常被视为anti-pattern。我曾经在StackOverflow上询问过question有关它们的信息,其中第一张图片可能是您实现它的方式:
这是根据Bill Karwin关于如何使用它来实现这个anti-pattern的建议(就像我自己一样,对我来说,这只是一种模式)。
事实上,这就像Faust的TPT解决方案(如果它对你有效,你应该接受它作为答案),特别是如果你扩展基表,其中包含三个类共有的所有属性。
在这种情况下,我更愿意在存储库Add
函数中处理它,在每个函数中为您添加的实体创建注释对象。