我的项目中有4个实体：项目，任务，注解，附加文件
在前3个实体中，用户可以将文件附加到它们，我认为这是一对多的关系，因此我在它们中引入了导航属性：
public List<AttachedFiles> AttachedFiles {get; set;}完成初始迁移后，EFCore在AttachedFiles表中创建了3个FK，我认为这是一个糟糕的设计，因为将来我可能会考虑从额外的源上传文件，每次都会向表中添加新的FK，从长远来看，也很难维护表。另外，另一个开发人员可能会在每个文件都应该与一个源相关时，为同一行填充2个FK。
我找到了两个解决方案：
1.在AttachedFiles表中引入OwnedId、OwnedType属性，并在插入时使用源的PK填充类型。
然而，这会带来更多的问题：这些表之间不会有显式关系，我无法引入导航属性以从EFCore中获益，因此我必须手动编写所有命令和查询，此外，如果PK已删除，文件仍将可用（删除时无级联操作）。
1.引入3个以上的实体，设置之间的源文件和附件。这样我就不会有问题的EFCore，但我认为关系将是多对多，而不是一对多。
有人对这个问题有建议或解决方案吗？或者我是否可以使用EFCore的第一个解决方案？
1条答案
按热度按时间ijxebb2r1#
引入3个以上的实体，设置之间的源文件和附件。这样我就不会有问题的EFCore，但我认为关系将是多对多，而不是一对多。
如果不需要多对多关系，则引入的三个实体应为PorobjectAttachedFile、UserAttachedFile和CommentAttachedFile。这些实体都可以从不是实体或在数据库中使用TPT继承的AttachedFile基类继承。