Question

I have several models in my project which really should be using identifying relationships, but I have them setup with unique auto-increment primary keys for speed and simplicity reasons. For example, email addresses in a contact:

Public Class EmailAddress
    'This is currently the primary key
    Public Property EmailAddressID As Integer

    'These three properties really make a composite primary key in an identifying relationship with contacts
    Public Property ContactID As Integer
    Public Property Address As String
    Public Property Domain As String
End Class

I have two questions about this setup:

1. Does having nvarchar field(s) inside a composite key really slow down the DB enough to warrant not using it (as I was led to believe in school)?
2. If yes to 1, is there a way (either in Data Annotations or the Fluent API) to inform EF that this is actually an identifying relationship with an artifical primary key and thus reap the benefits (under heading “Considerations for Identifying and Non-identifying Relationships”)?

Answer 1

1. No. Keys are a logical, data integrity feature; performance depends on many other things.

2. In the relational model and in SQL the distinction between an identifying and non-identifying relationship is of very little or no importance at all. You may find such terms helpful as a way of understanding a conceptual model but they are not really a sound basis for making database design decisions. The alleged “benefits” you refer to are essentially just syntactic sugar.