实体框架关系匹配-数据库中没有外键

Question

I've gone through the Entity Framework code-first tutorials and I hate to say but I'm at a loss for how it works. Everything works but I want to know how because everything I know about basic database design tells me it shouldn't. I feel like I'm missing a critical link with how it's creating foreign keys and hope someone can explain it.

I initially copied and pasted a bunch of code-first designs of a simple Parent class with multiple child types. In my child types I had a reference to the virtual Parent and a ParentID reference. I noticed in the database that the value of ParentID was 0 for every single child of type A and B.

However, when loading the data in code and debugging/displaying, entity relationships were correctly maintained.

The code looks like (class names were changed to remove context of what it is):

public class Parent{
    public int? ParentID {get;set;}
    public virtual ChildA ChildA {get;set;}
    public virtual ChildB ChildB {get;set;}
}

public class ChildA{
    [Key,ForeignKey(Parent)]
    public int ChildAID {get;set;}

    public string Field {get;set;}

    //public int ParentID {get;set;}

    [ForeignKey("ParentID")]
    public virtual Parent Parent {get;set;}
}

public class ChildB{
    [Key,ForeignKey(Parent)]
    public int ChildBID {get;set;}

    public string Field {get;set;}

    //public int ParentID {get;set;}

    [ForeignKey("ParentID")]
    public virtual Parent Parent {get;set;}
}

I commented out the ParentID to show explicitly what I was talking about. To test this out, I deleted the column in the database and yet the relationships still work correctly. There are only three tables that relate to this in the database (Parent, ChildA, and ChildB). There aren't any foreign keys, and the parent table doesn't reference the children tables and the children tables don't reference the parent table. When I load them from the DBContext , the mappings correctly load them as I saved them.

What am I missing here? Something somewhere is keeping track of this mapping but I can't tell where. And the fact that it isn't stored as a really basic foreign key in the database concerns me about performance.

Answer 1

What do you mean by There aren't any foreign keys, and the parent table doesn't reference the children tables and the children tables don't reference the parent table. ?

I think you were missing to notice that there are relationship between them.

It's called one to zero-or-one relationship.

Answer 2

Your question is a bit baffling because Entity Framework does store relationships as "really basic foreign keys", so I can't see how you've come to that conclusion.

Commenting out the ParentID to show what your talking about doesn't help much because it should actually have had no effect. That is because when you add the [ForeignKey("ParentID")] attribute to the Parent property, you are telling Entity Framework to put a foreign key in the database named "ParentID" to model the Parent relationship.

You don't need the ParentID integer property in your Entity, but it is usually easier to include foreign keys, and most examples show this.

Now, if you do include ParentID, then you don't need the [ForeignKey("ParentID")] attribute on the Parent property because EF will assume that ParentID is the foreign key for the Parent navigation property because you have followed a standard naming convention.

Also you could try this - remove both the ParentID and the [ForeignKey("ParentID"] attribute and update the database. Now you should find that EF has added a foreign key named "Parent_Id". So foreign keys used always!

The [Key,ForeignKey(Parent)] attribute on your keys looks wrong. The ID isn't a navigation property so you don't need to specify a foreign key for it, so I'm not sure what that is doing (actually, on second thoughts, this may be your problem, I think this is specifying a one to one). That Key attribute is also unnecessary because again you have followed a naming convention.

So in summary, get shot of all your attributes and follow the naming conventions until you need to do something tricky!