You should only set a property of a temporal type (like DateTime or DateTimeOffset) as the primary key of a table if the
values are guaranteed to be unique.
Why is this an issue?
Using temporal types as the primary key of a table is risky. When these types are used as primary keys, it usually means that each new key is
created with the use of .Now or .UtcNow properties from DateTime and DateTimeOffset classes. In
those cases, duplicate keys exceptions may occur in many ways:
- when entries are added consecutively by a machine with low-enough system clock resolution;
- when two different threads are inserting entries in close enough sequence for both to have the same time;
- when changes such as daylight saving time (DST) transitions occur, where values can be repeated the following hour (only for
DateTime type);
The rule raises an issue if:
- Entity Framework, or Entity Framework Core dependencies are found;
- a class contains a property either named
Id, <type name>Id or decorated by the [Key] or
[PrimaryKey] attribute.
- the key property is of one of the following types:
How to fix it
Either use a GUID or the auto generated ID as a primary key.
Code examples
Noncompliant code example
Public Class Account
Public Property Id As DateTime
Public Property Name As String
Public Property Surname As String
End Class
Compliant solution
Public Class Account
Public Property Id As Guid
Public Property Name As String
Public Property Surname As String
End Class
or
Noncompliant code example
Public Class Person
<Key>
Public Property PersonIdentifier As DateTime
Public Property Name As String
Public Property Surname As String
End Class
Compliant solution
Public Class Person
<Key>
Public Property PersonIdentifier As Guid
Public Property Name As String
Public Property Surname As String
End Class
Resources
Documentation
