Apart from what Solution 1 tells, I have to recommend another approach. That approach is, to use string as the ID field in Entity Framework Core, and framework will automatically use Guid to generate the unique IDs. I have always used this, and this lets me sleep peacefully at night.
Make the following changes,
public class Employee {
public string EmployeeId { get; set; }
}
And leave everything else to the EF Core.
What are the downsides? Well, you cannot see if an employee was registered before, or later just by looking at their ID. However, you can tell that by their
joiningDate
field. Also, SQL Server notably uses a seed value. That can grow exponentially and will result is answers like, 1, 2, 3, 10, 15, 17, 18, 100, 101, 500, and so on. Do that want that? Not exactly. Thus, take my advice if you can, use string as a primary key field and live at peace. :-)
SQL Server 2012 column identity increment jumping from 6 to 1000+ on 7th entry - Stack Overflow[
^]
I can assume that you really want to showcase this ID on their ID or something too, in that case, try to store that EmployeeNumber as a separate field that stores the ordinal value, coming in the sequence as they join your organization, and leave the primary key to be the one generated by ORM—
my apologies to the normalization-is-needed-geeks.